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本 书 推荐 语 


对 于 像 Android、Linux 这 样 复杂 的 大 型 软件 ， 泛 泛 了 解 一 下 工作 原理 并 不 难 ， 看 看 文 
档 ， 或 者 随便 找 几 本 书 看 看 ， 再 实际 用 一 下 体验 体验 ， 也 就 差不多 了 。 
但 是 若 想 要 有 比较 深入 透彻 的 理解 ， 那 就 非得 要 阅读 分 析 其 源 代码 不 可 ， 这 就 比较 难 
了 .。 这 时 候 ， 如 果 有 人 先行 一 步 ， 下 了 苦 功 先 把 它 弄 懂 ， 再 把 所 获 的 知识 和 心得 分 享 出 来 ， 
那 就 是 很 有 价值 了 。 我 觉得 王 森 这 本 书 就 是 这 样 ， 里 面 不 光 有 代码 的 分 析 , 还 有 他 的 见解 ， 
特别 是 还 有 他 的 一 些 经 验 之 谈 ， 相 信 读 者 会 和 我 一 样 看 了 后 觉得 受益 匪 浅 。 
一 一 《Linux 内 核 源 代码 情景 分 析 》 作 者 毛 德 操 


Android 系统 几 年 来 高 速 发 展 ， 不 过 国内 工程 师 使 用 者 居多 ,深入 了 解 者 少 。 本 书 深 
入 浅 出 ,将 作者 多 年 实践 经 验 结 合 系统 深层 探索 呈现 给 大 家 ，, 可谓 雪 中 送 炭 、 广 大 Android 
工程 师 的 福音 。 感 谢 本 书 作者 的 分 享 ， 相 信 本 书 会 成 为 工程 师 们 进 阶 修炼 的 极 大 助力 。 
北京 时 代 飞 腾 科 技 有 限 公司 技术 总 监 刘 天 宇 


本 书 内 容 风趣 幽默 且 比 喻 贴切 , “Android 与 Linux 内 核 的 关系 ， 就 好 比 一 辆 整 车 和 底 

盘 发 动机 的 关系 ”; 该 书 内 容 详实 而 又 丰富 , 既 有 MTK 平台 的 知识 , 又 有 三 星 平台 的 细节 ， 

既 有 Linux 基于 ARM 的 实现 细节 , 又 有 Android 的 原理 和 机 制 . 作者 苦心 钻研 , 颇 有 心得 ， 

深入 浅 出 又 提纲 插 领 地 将 ARM 和 Android 的 核心 机 密 全 盘 托 出 ， 相 信 此 书 定 会 给 无 论 是 
初学 者 还 是 资深 开发 者 带 来 帮助 和 益处 。 

一 一 三 星 半导体 杭州 研究 所 资深 软件 工程 师 张 秀 文 


本 书 在 着 力 分 析 Android 系统 最 常用 到 的 内 核 机 制 之 后 ， 继 续 向 上 剖析 Android 用 户 

层 核心 机 制 是 如 何 接 驳 Linux 内 核 的 。 而 且 书 中 分 析 涉 及 到 ARM 体系 为 较 新 Cortex A9 
SMP 架构 ， 对 于 读者 开发 、 研 究 工作 有 着 实际 的 借鉴 作用 。 

一 一 红 狼 软件 创始 人 ;《 深 入 剖析 Android 系统 》 作 者 杨 长 刚 


记得 当年 从 研一 开始 , 本 书 作 者 就 埋头 于 Linux 源 代码 的 学 习 、 分 析 , 梦想 着 了 解 Linux 
的 每 一 个 角落 。 虽 然 他 常常 不 修 边 幅 ， 但 只 要 谈 起 编程 或 Linux 源 代码 他 就 两 眼 放 光 ， 江 
滔 不 绝地 大 谈 特 谈心 得 体会 。 那 时 他 的 执着 就 让 我 十 分 钦佩 。 一 晃 十 多 年 过 去 了 ， 本 书 作 
者 仍旧 是 那个 严肃 的 程序 员 ， 依 旧 在 执着 地 追求 着 他 的 梦想 。 

如 果 你 也 是 一 位 严肃 的 程序 员 ， 有 兴趣 ， 有 毅力 去 了 解 Android 的 实现 ; 或 者 你 是 一 
个 Android 系统 开发 人 员 ， 推 荐 把 本 书 作为 手边 的 参考 书 。 源 代码 注释 的 写作 方式 看 起 来 
有 些 简陋 ,但 是 这 样 对 阅读 Android 源 代码 非常 有 帮助 ， 根 据 书 中 的 代码 段 可 以 很 容易 地 
搜索 到 你 关注 的 Android 源 代码 ， 从 而 大 大 缩短 学 习 时 间 。 

一 一 本 书 作者 同学 ; CA Technologies 研发 经 理 王 晋 


了 中 
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1996 年 ， 面 对 闪烁 的 DOS 提示 符 ， 笔 者 心中 产生 了 一 个 愿望 
一 条 指令 是 如 何 工 作 的 。 

2000 年 ， 笔 者 明白 一 个 道理 ， 内 核 才 是 机 器 的 灵魂 ， 只 有 阅读 源码 才能 与 机 器 的 灵魂 
对 话 。 于 是 笔者 开始 了 漫长 的 源码 阅读 之 旅 。 

2008 年 ， 在 经 历 了 近 十 年 内 核 以 及 驱动 项 目 开发 后 ， 笔 者 发 现 尽管 玄机 重重 ， 但 是 内 
核 并 非 不 能 驾驭 。 在 浩如烟海 的 Linux 代码 里 有 一 个 清晰 的 内 核 骨架 ，Linux 各 种 文件 、 
驱动 子 系统 围绕 该 骨架 接 驳 起 来 ， 把 握 住 这 个 骨架 就 驾驭 了 Linux。 

然而 痛苦 随 之 而 来 ， 以 前 笔者 以 为 内 核 就 是 一 切 ， 驾 驭 了 内 核 就 理解 了 机 器 的 一 切 。 
但 是 实际 上 ， 内 核 不 是 全 部 ， 要 理解 机 器 的 机 理 还 需要 操作 系统 领域 的 探索 ， 在 经 历 了 
Glibce、X、GTK 等 痛苦 且 失 败 的 探索 之 后 ， 笔 者 发 现 了 Android。 

2011 年 ， 笔 者 多 年 的 心愿 总 算 有 个 了 结 。 在 经 历 了 2 年 多 Android 源码 研究 之 后 ， 终 
于 理解 了 Android 如 何 将 内 核 的 强大 能 量 释放 给 应 用 程序 ， 如 何 对 传统 内 核 加 以 巧妙 改造 
以 满足 当今 以 面向 对 象 机 制 为 基础 的 软件 体系 。 这 一 年 又 是 新 的 开始 ， 一 次 难得 的 机 会 ， 
笔者 能 够 深入 硬件 开发 。 

2013 年 ， 这 两 年 可 谓 笔者 的 硬件 生涯 。 无 论 是 原理 图 、PCB 设计 还 是 选择 制 板 工厂 、 
实施 备料 、 贴 片 试 产 跟 线 ， 笔 者 都 能 够 有 幸 深 入 一 线 体 验 硬 件 工程 的 复杂 与 艰辛 。 笔 者 党 
试 了 软 硬 件 协同 设计 ， 尽 管 在 板 级 设计 这 一 层面 作用 有 限 ， 但 是 通盘 软考 虑 依然 可 以 避免 
不 少 工程 误区 。 

2014 年 ， 笔 者 将 这 些 年 的 笔记 进行 整理 ， 揭 成 此 书 ， 也 算是 个 人 生 的 小 结 吧 。 

本 书 其 实 是 实现 本 人 年 少时 梦想 的 一 部 分 一 一 理解 计算 机 每 一 条 指令 是 如 何 工作 的 。 

然而 ， 这 只 是 一 个 梦想 ， 操 作 系 统 如 同 浩如烟海 的 原始 森林 ， 每 一 条 指令 只 是 其 中 的 
一 片 树叶 ， 人 们 不 可 能 读 完 每 一 行 代码 ， 也 没有 必要 这 样 做 。 任 何 一 个 优秀 的 操作 系统 都 
有 一 个 精 悍 的 架构 ，Android 系统 也 不 例外 ， 本 书 通过 分 析 这 个 架构 来 阐述 Android 机 理 。 

笔者 认为 ， 尽 管 Android 用 户 层面 的 代码 量 远 大 于 内 核 部 分 ， 但 是 其 关键 架构 却 与 内 
核 息 息 相 关 ， 且 其 功能 部 分 架构 已 经 有 很 多 优秀 书籍 和 资料 阐述 。 所 以 本 书 更 多 着 墨 于 
Android 内 核 表 现 以 及 内 核 机 制 的 Android 运用 。 

最 后 需要 提醒 读者 的 是 ， 无 论 多 丰富 的 语言 在 源码 面前 也 是 苍白 的 ， 本 书 选择 通过 源 
码 注释 的 方式 来 描述 Android 架构 ， 建 议 读者 结合 源码 来 阅读 本 书 。 
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Android 与 Linux 内 核 的 关系 ， 就 好 比 一 辆 整 车 和 底盘 发 动机 的 关系 。 作 为 
底盘 和 发 动机 的 Linux 内 核 ， 尽 管 不 能 直接 被 用 户 和 应 用 开发 者 感知 到 ， 但 是 
却 决定 了 Android 系统 运行 时 最 核心 的 机 制 。 
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计算 性 能 是 处 理 器 演进 的 第 一 动力 。 然 而 ， 尽 管 各 种 架构 的 高 性 能 处 理 器 层出不穷， 
但 真正 大 规模 普及 开 来 的 似乎 只 有 Intel 和 ARM 体系 .观察 其 中 的 现象 不 难 发 现 如 下 规律 。 

虽然 处 理 器 性 能 得 到 大 幅 改 善 ， 但 如 果 无 法 得 到 现 有 主流 操作 系统 的 支持 ， 就 无 法 大 
规模 应 用 。 进 一 步 来 讲 ， 即 使 某 种 处 理 器 得 到 主流 操作 系统 的 支持 ， 但 是 由 于 其 指令 集 的 
不 兼容 性 ， 导 致 大 量 的 应 用 无 法 运行 ， 这 种 处 理 器 也 是 难以 普及 的 ， 安 腾 的 失败 是 个 很 好 
的 例子 。 

“兼容 性 ”是 处 理 器 演进 的 第 一 法 则 。 现 有 的 软件 体系 是 计算 机 世界 的 主 室 ， 所 有 不 
服从 现在 软件 体系 的 指令 集 都 只 能 被 边缘 化 或 者 被 淘汰 。 所 以 看 到 Intel 和 ARM 不 断 扩展 
寄存 器 长 度 、 增 加 发 射 单元 、 支 持 乱 序 、 扩 展 总 线 单元 等 一 系列 手段 来 改进 处 理 器 架构 ， 
就 是 不 敢 废 弃 一 条 既 有 指令 。 

降低 计算 功 耗 是 处 理 器 演进 的 第 二 动力 。 对 于 服务 器 来 说 功 耗 就 是 运营 成 本 ， 对 于 移 
动 计算 来 说 功 耗 就 是 生命 。 似 乎 台式 机 功 耗 要 求 不 大 ， 但 是 台式 机 与 服务 器 、 移 动 设备 不 
仅 在 处 理 器 的 生产 及 设计 上 共享 基础 设施 外 ， 软 件 体 系 也 有 着 相同 的 基础 ， 导 致 整个 软件 
体系 为 了 照顾 移动 设备 和 服务 器 而 收敛 了 扩张 的 步伐 。 这 就 是 人 们 常 说 的 “计算 过 剩 ”， 其 
实 计算 永远 不 会 过 剩 ， 只 是 庞大 的 软件 体系 有 所 收敛 罢了 。 

频率 提升 是 功 耗 的 大 敌 ， 为 了 提高 能 耗 比 ， 设 计 频 率 更 低 而 核心 更 多 的 处 理 器 是 好 的 
方法 ， 由 此 ， 近 年 来 处 理 器 的 扩张 由 单 核 高 频 转 变 为 多 核 体系 。 

Linux 支持 的 多 核 体系 的 基本 特点 为 : 所 有 处 理 器 拥有 完全 相同 的 指令 集 ， 所 有 处 理 
器 共享 同一 内 存 。 如 果 不 符 合 以 上 任何 一 点 , 操作 系统 内 核 都 需要 做 架构 及 修改 才能 支持 。 
若 满足 这 两 个 前 提 ， 其 他 方面 的 问题 ， 都 可 以 通过 内 核 和 系统 小 规模 修改 来 支持 。 如 
Big.little 架构 下 互相 搭配 的 处 理 器 尽管 核心 内 部 实现 不 同 ， 但 各 核心 有 着 相同 的 指令 集 ， 
Linux 内 核 可 以 将 它们 当 作 同 样 的 处 理 器 来 分 配 线程 。 内核 在 完全 不 加 改动 的 情况 下 , 也 许 
会 出 现 一 个 重量 级 线程 被 分 配 到 了 一 个 little 的 核心 上 , 但 是 内 核 本 身 可 以 通过 处 理 器 负载 
均衡 将 其 平衡 到 别 的 处 理 器 上 。 当 little 负载 较 高 时 ，big 必定 会 上 线 运行 ， 但 是 系统 有 可 
能 会 出 现 重负 载 线程 独自 霸占 little 的 情形 的 极限 情况 ， 这 时 需要 将 调度 算法 稍 加 修改 , 首 
先 记 录 每 个 处 理 器 能 力 , 然后 监测 little 上 单线 程 高 负载 发 生 的 时 长 , 若 超 出 一 定 阀 值 则 将 
高 负载 线程 时 间 片 减 为 零 ， 从 little 摘 下 来 ， 再 将 其 挂 到 big 处 理 器 运行 队列 即 可 。 
进一步 讲 ， 多 核心 之 间 只 要 基本 的 读 写 、 跳 转 之 类 指令 相同 ， 其 余 指 令 集 不 同 ，Linux 
也 可 以 支持 的 。 内 核 只 需 用 到 基本 指令 即 可 ， 各 核心 用 户 空间 指令 可 以 不 同 。 内 核 需 做 如 
下 修改 : 每 颗 核心 的 调度 队列 记录 下 其 核心 用 户 态 指令 集 特 性 ， 每 个 线程 创建 之 初 申明 自 
身 需 要 的 指令 集 特 性 ， 内 核 在 给 线程 分 配 核心 及 做 负载 均衡 时 比较 两 者 是 否 匹 配 。 用 户 层 
动态 加 载 器 也 要 做 修改 ， 针 对 当前 处 理 器 指令 集 特 性 动态 加 载 、 跳 转 到 不 同 版 本 的 动态 库 
中 ， 且 在 动态 库 执行 过 程 中 标记 自身 线程 不 可 切换 处 理 器 。 当 然 这 种 复杂 情况 超出 了 当前 
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现状 ， 尽管 有 用 户 态 指令 集 不 同 的 架构 ， 但 是 运行 指令 集 差 集 的 线程 不 需要 动态 加 载 库 的 
支持 ， 且 直接 绑 定 到 指定 核心 上 。 


1.1 SMP 相关 基础 数据 结构 


CPU 管理 的 特点 是 自我 管理 ， 除 了 在 启动 、 休 了 眠 、 调 频 受 控 于 CPUO 的 工作 以 外 ， 处 
理 器 相关 的 绝 大 部 分 工作 都 由 处 理 器 自我 管理 。 处 理 器 是 内 核 的 执行 体 ， 又 被 内 核 控制 。 
ni rea np hi 处 理 器 在 运行 时 将 自己 的 状态 记录 在 
结构 中 ， 而 处 理 器 也 能 通过 别 的 处 理 器 的 表征 结构 了 解 其 他 处 理 器 状态 或 发 起 控制 。 
0 CPU 都 对 应 一 个 通用 CPU 结构 ， 将 ARM Core 与 device 联系 起 来 。 
struct cpu { 
/*cpu 编号 */ 
int node id; 
/* 对 于 arm smp 该 值 为 真 ， 表 示 每 颗 cpu 都 可 以 被 关 掉 */ 
int hotpluggable; 
/* 正 如 每 个 外 设 都 有 一 个 struct device 表示 自身 一 样 ，cpu 也 不 例外 */ 
struct device dev; 


}; 

处 理 器 在 内 核 中 也 被 作为 系统 设备 存在 ， 而 其 相关 操作 以 驱动 形式 通过 处 理 器 系统 设 
备 类 一 一 struct sysdev_class cpu sysdev_class 来 识别 管理 处 理 器 。 在 处 理 器 拓扑 初始 化 时 ， 
内 核 完 成 设备 侧 的 注册 。 


// 处 理 器 拓扑 初始 化 
static int _init topology init (void) 


{ 


/* 对 于 每 个 物理 存在 处 理 器 的 操作 ， 位 图 cpu_possible_bits 描述 了 系统 中 的 处 理 器 ， 无 
论处 理 器 是 否 online， 都 对 应 其 中 一 位 */ 
for each possible_cpu(cpu) { 
struct cpuinfo arm *cpuinfo = &per cpul(cpu data, cpu); 
/*ARM SMP 的 架构 是 每 个 core 都 可 以 被 单独 关闭 的 */ 
cpuinfo->cpu.hotpluggable = 1; 
/* 将 当前 cpu 的 struct device 注册 到 struct sysdev_class cpu_sysdev_class*/ 


register cpul(&gcpuinfo->cpu, cpu); 
} 
// 注 册 一 颗 处 理 器 的 设备 


int _cpuinit register_cpu (struct cpu *cpu, int num) 


: 
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// 对 CA9, 非 NUMA, 为 0 
cpu->node id = cpu to node (num); 


cpu->sysdev.id = num; 


// 处 理 器 系统 设备 类 

Cpu->sysdev.cls = g&cpu sysdev class; 

/* 向 处 理 器 系统 设备 类 注册 该 处 理 器 ， 在 每 注册 一 个 设备 时 ， 都 会 调用 设备 类 驱动 来 初始 化 
该 驱动 */ 


error = sysdev register (gcpu->sysdev); 


. 


在 对 方 驱动 人 出 , 通过 向 处 理 器 系统 设备 类 注册 驱动 来 匹配 初始 化 处 理 器 ,参见 1.3 节 。 

struct cpuinfo_arm 对 应 于 每 颗 Arm core 实体 ， 记 录 其 基本 信息 ， 在 ARM 初始 化 时 会 
依次 初始 化 并 注册 每 个 struct cpuinfo_arm。 

struct cpuinfo arm { 

struct cpu cpu; 
#ifdef CONFIG SMP 
// 当 前 cpu 的 idle 线程 
struct task struct *idle; 
unsigned int loops per jiffy; 

#endif 

}; 

CPU 设备 集合 ， 每 个 CPU 的 struct device 和 struct sysdev_driver 都 会 被 加 进来 。 这 是 
联系 CPU 设备 集合 类 驱动 的 纽带 ， 当 CPU 设备 或 驱动 注册 的 时 候 ， 会 依次 扫描 这 里 的 驱 
动 列表 或 CPU 设备 ， 并 进行 初始 化 ， 如 cpufreq_sysdev_driver。 

struct sysdev_class cpu sysdev class = { 

.name = "cpu", 


-attrs = cpu sysdev class attrs, 


}; 
struct cpumask: CPU 状态 的 基本 数据 结构 定义 如 下 : 


typedef struct cpumask { DECLARE BITMAP (bits, NR CPUS); } cpumask t; 
#define DECLARE BITMAP (name,bits) \ 
unsigned long name [BITS TO LONGS (bits)] 


展开 如 下 : 


typedef struct cpumask { unsigned long bits[BITS TO LONGS(NR CPUS)] } 


cpumask t; 


cpu_possible_mask 位 图 ， 用 来 表示 系统 中 的 CPU， 每 颗 处 理 器 对 应 其 中 一 位 。 
cpu_online mask 位 图 ， 用 来 表示 当前 处 于 工作 状态 的 CPU， 每 颗 处 理 器 对 应 其 中 一 位 。 


cpu bit bitmap: 
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const unsigned long cpu bit bitmap[BITS PER LONG+1] [BITS TO LONGS (NR_CPUS) 


对 于 双核 CA9， 这 个 数组 是 const unsigned long cpu_bit_bitmap[33][1]。 可 见 这 是 列 数 


为 1 的 数组 。 其 中 列 数 与 CPU 个 数 和 sizeoftlong) 有 关 。 每 颗 CPU 对 应 一 行 ， 但 是 最 上 面 
的 一 行 是 保留 不 用 的 。 


// 接 下 来 是 该 位 图 具体 的 定义 ， 通 过 一 组 宏 来 实现 
const unsigned long cpu bit bitmap[BITS PER LONG+1] [BITS TO LONGS (NR 
CPUS)] = { 

MASK DECLARE 8(0), MASK DECLRRE 8(8) ， 


MASK_DECLARE 8(48), MASK DECLARE 8(56), 
}; 


CPU0 一 CPU7 对 应 于 前 8 个 数据 ， 其 宏 定 义 为 MASK_DECLARE 8(0)， 接 下 来 以 此 


为 例 ， 通 过 相关 宏 定 义 的 层 层 奉 代 ， 分 析 处 理 器 位 图 结构 。 


第 1 步 ， 展 开 顶 层 宏 : 

#define MASK DECLARE 8(x) MASK DECLARE 4(x), MASK DECLARE 4 (x+4) 
得 到 如 下 第 二 层 宏 数组 : 

MASK_DECLARE 4(0), MASK_ DECLARE 4(0+4) 

#define MASK DECLARE 4 (x)MASK DECLARE 2(x), MASK DECLARE 2 (x+2) 
展开 ， 得 到 第 三 层 宏 数 组 : 

MASK_DECLARE 2(0), MASK DECLARE 2(0+2); MASK DECLARE 2(4), MASK DECLARE 2 (4+2 
第 3 步 ， 将 宏 定义 : 

#define MASK DECLARE 2 (x)MASK DECLARE 1 (x), MASK DECLARE 1 (x+1) 
展开 ， 得 到 第 四 层 宏 数 组 : 

MASK_DECLARE 1(0), MASK DECLARE 1(0+1): 

MASK_DECLARE 1(6), MASK DECLARE 1 (6+1) 

最 后 ， 再 将 宏 定义 


#define MASK DECLARE 1 (x) 


替换 为 

[x+1] [0] = (10L << (x)) 
得 到 如 下 序列 : 

[1][0] = (1UL << (0)) 


[2][0] = (10D << (1)) 
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[8] [0] = (10D << (7)) 


由 此 可 见 ， 第 0 行 没有 初始 化 。 对 于 CPU0、CPU1， 其 MASK 分 别 对 应 第 1 行 和 第 2 
行 ， 值 分 别 为 LUL<< (0)，(IUL << (1))。 

而 对 于 CPU8 一 31， 则 由 MASK DECLARE 8(8) 、MASK DECLARE 8(16) 、 
MASK DECLARE 8(24) 定 义 了 对 应 的 MASK 了 ， 其 过 程 与 MASK DECLARE 8(0) 类 似 ， 
这 里 不 做 展开 。 


1.2 Percpu 内 存 管理 


随 着 处 理 器 核心 的 增加 ， 内 核 中 系统 中 并 发 的 线程 也 随 之 增加 ， 这 样 对 一 些 共 享 数据 
同时 访问 的 几率 也 就 增加 ， 就 避免 不 了 使 用 spin_lock， 而 且 往 往 处 理 器 核心 越 多 造成 的 麻 
烦 越 大 。Percpu 内 存 对 这 种 数据 无 能 为 力 ， 但 是 内 核 中 有 些 数据 只 是 处 理 器 局 部 ， 可 见 ， 
这 种 数据 不 会 被 别 的 处 理 器 访问 到 , 不 需要 加 以 spin_lock 而 直接 访问 。Percpu 内 存 适 用 于 
这 种 数据 ， 而 实际 上 处 理 器 局 部 数据 的 实际 分 配 还 是 通过 内 核 基本 slab 进行 ， 而 Percpu 
内 存 则 是 用 来 存放 指向 处 理 器 局 部 数据 的 指针 。 


1.2.1 内 核 显 式 定义 的 处 理 器 局 部 数据 


这 是 在 内 核 代 码 中 手工 定义 的 变量 ， 但 是 这 些 数 据 比 较 特 殊 ， 内 核定 义 与 引用 时 使 用 
a 链接 时 被 集中 排放 在 特殊 的 地 址 上 ， 内 核 初始 化 时 有 着 专门 的 指针 处 理 。 本 节 

关 分 析 围 绕 这 些 方面 展开 。 

首先 分 析 链接 文件 arch/arm/kermel/vmlinux.lds.S 中 定义 的 这 些 特殊 地 址 。 

展开 宏 : PERCPU_ SECTION(32) 


#define PERCPU SECTION (cacheline) 
- = ALIGN (PAGE SIZE); \ 
.data. .percpu : AT(ADDR(.data..percpu) - LOAD OFFSET) { \ 
VMLINUX SYMBOL(_ per cpu load) = .; \ 
PERCPU_INPUT (cacheline) \ 


} 


#define PERCPU INPUT (cacheline) 
VMLINUX SYMBOL(_ per cpu start) = .; 
*(.data. .percpu. .first) 
- = ALIGN (PAGE _ SIZE) 
#(.data.-percpu..page_aligned) 
- = ALIGN(cacheline); 
*#(-data. -percpu.- .readmost1l1Yy) 
- = ALIGN(cacheline); 
*(.data. -percpu) 


i a a 


*(.data. .percpu. .shared aligned) 
VMLINUX SYMBOL( per cpu end) = .; 
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该 宏 的 作用 是 声明 了 以 .data..percpu..first、.data..percpu..readmostly、.data..percpu 等 为 
名 字 的 数据 段 ， 内 核 代码 中 如 果 有 变量 的 属性 指出 放 在 该 数据 段 的 时 候 ， 链 接 时 将 其 分 配 
到 对 应 的 数据 段 .而 且 为 了 能 够 在 内 核 里 直接 访问 这 段 区 域 ,定义 两 个 变量 :_ per_cpu_start 
和 _per_ cpu end。 

在 内 核 编码 时 ， 对 处 理 器 局 部 数据 的 定义 需 使 用 特殊 的 宏 (DEFINE_PER_CPU) 来 完 
成 。 这 里 分 析 (DEFINE PER_CPU) 的 实现 。 

层 层 展开 该 宏 : 

#define DEFINE PER CPU (type, name) % 

DEFINE PER CPU SECTION (type, name, "") 


#define DEFINE PER CPU SECTION (type, name, sec) NV 
_PCPU ATTRS (sec) PER CPU DEF ATTRIBUTES SN 
_ typeof (type) name 


#define _ PCPU ATTRS (sec) N 
percpu _attribute ((section(PER CPU BASE SECTION sec))) \ 
PER_CPU_ATTRIBUTES 


#define PER CPU BASE SECTION ".data..percpu" 
根据 以 上 宏 定 义 展开 之 : 可 以 得 到 
_attribute ((section(.data..percpu))) typeof _ (type) name 


可 见 宏 DEFINE_PER_CPU(type, name) 的 作用 就 是 将 类 型 为 type 的 name 变量 放 
到 .data..percpu 数据 段 中 。 

同样 方法 可 以 推出 : 宏 DECLARE PER_CPU_READ _MOSTLY(type, name) 的 作用 就 是 
将 类 型 为 type 的 name 变量 放 到 .data..percpu..readmostly 数据 段 中 。 这 种 数据 段 是 cacheline 
对 齐 ， 可 以 大 大 提高 cache 的 利用 率 ， 很 适合 频繁 读 取 数据 ， 不 过 在 笔者 分 析 的 这 个 内 核 
版 本 3.0.13 中 ， 内 核 中 这 种 数据 还 没有 大 规模 使 用 的 。 而 且 cacheline 定义 为 32， 对 于 不 
同 架 构 可 以 使 用 时 适当 调整 。 

另外 宏 DECLARE PER_CPU FIRST(type, name) 对 应 .data..percpu..first 数据 段 。 

宏 DECLARE PER_ CPU PAGE _ ALIGNED 对 应 .data..percpu..first” 数 据 段 。 

内 核 初 始 化 过 程 中 ， 会 为 每 个 处 理 器 定位 链接 进 镜像 的 局 部 数据 。 

// 初 始 化 是 。”_per_cpu_offset 的 建立 

void _init setup per cpu areas (void) 

{ 

rc = pcpu embed first chunk (PERCPU MODULE RESERVE, 
PERCPU DYNAMIC RESERVE, PAGE SIZE, NULL, 
pcpu dfl fc alloc, pcpu dfl fc free); 


delta= (unsigned long)pcpu base addr - (unsigned long) per cpu start; 
/* 设 置 每 个 cpu 的 ”_per cpu _ offset 指针 */ 
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for each possible_cpu(cpu) 
_ _per cpu offset[cpu] = delta + pcpu unit offsets[cpu]; 
} 


再 看 对 内 核 中 对 percpu 数据 的 引用 : 内 核 通过 宏 per_cpu 对 定义 的 处 理 器 局 部 数据 的 
引用 ， 展 开 该 宏 : 


#define per cpulvar, cpu) \ 
(*SHIFT PERCPU PTR(&(var), per cpu offset (cpu))) 


#define SHIFT PERCPU PTR(_ Pp, _ offset) ({ \ 
_ verify pcpu ptr((_ p)); \ 
RELOC HIDE((typeof (*(_ p)) kernel _force *)( pp), (_ offset)); \ 


法 
#define per cpu offset (x) (_ per cpu offset[x]) 


/* 选 用 一 个 简单 易 看 得 RELOC_HIDE 宏 定义 */ 


# define RELOC HIDE (ptr, off) % 
({ unsigned long _ptr; % 
_ptr = (unsigned long) (ptr); 


(typeof (ptr)) (_ ptr + (off)); }) 
可 见 是 以 当前 CPU 局 部 数据 _per_cpu_offset[x] 为 基地 址 的 相对 寻 址 。 


1.2.2 ”Percpu 内 存 管理 的 建立 


在 建立 Percpu 内 存 管 理 机 制 之 前 要 整理 出 该 架构 下 的 处 理 器 信息 , 包括 处 理 器 如 何 分 
组 、 每 组 对 应 的 处 理 器 位 图 、 静 态 定义 的 Percpu 变量 占用 内 存 区 域 、 每 颗 处 理 器 Percpu 
虚拟 内 存 递 进 基本 单位 等 信息 。 本 文 仅 以 双核 CA9 处 理 器 作为 分 析 目 标 。 
对 于 处 理 器 的 分 组 信息 ， 内 核 使 用 struct pcpu_group_info 结构 表示 : 
struct pcpu group info { 
/* 该 组 的 处 理 器 数目 ， 对 于 双核 CA9 处 理 器 ， 该 值 为 2 */ 
int nr units; 
/* 组 内 处 理 器 数目 X 处理 器 percpu 虚拟 内 存 递 进 基 本 单位 */ 
unsigned long base offset; 
/* 组 内 处 理 器 对 应 数组 ， 双 核 CA9 架构 下 该 数组 长 度 为 2*/ 
unsigned int *cpu map; 
坟 
整体 的 Percpu 内 存 管 理 信息 被 收集 在 struct pcpu_alloc_info 结构 中 : 
struct pcpu alloc info { 
/ /静态 定义 的 percpu 变量 占用 内 存 区 域 长 度 


size 七 static size; 


/* 预 留 区 域 ， 在 percpu 内 存 分 配 指定 为 预 留 区 域 分 配 时 ， 将 使 用 该 区 域 */ 
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size 七 reserved size; 

size 七 dyn size 

/* 每 颗 处 理 器 的 percpu 虚拟 内 存 递 进 基 本 单位 */ 
size 七 unit size; 


/* 该 架构 下 的 处 理 器 分 组 数目 ，CA9 双核 架构 下 该 值 为 1*/ 


int nr groups; 


/* 该 架构 下 的 处 理 器 分 组 信息 ，CA9 双核 架构 下 该 数组 长 度 为 1*/ 


}; 


struct pcpu group info groups[]; 


接 下 来 构建 静态 定义 的 percpu 变量 创建 percpu 区 域 : 


/* 该 函数 被 void ”init setup per cpu areas (void) 调用 ， 对 于 CA9 架构 其 参数 


cpu_distance fn 为 NULL, 参数 alloc fn 为 pcpu dfl fc alloc*/ 


int _init pcpu embed first chunk(size t reserved size, size t dyn size, 


size t atom size, 

pcpu fc cpu distance fn t cpu distance fn, 
pcpu fc alloc fn t alloc fn， 

pepu fe free fnt free fn) 


void *base = (void *)ULONG MAX; 

void **areas = NULL; 

struct pcpu alloc info *ai; 

size t size sum, areas size, max distance; 

int group, i Te 

/* 收 集 整 理 该 架构 下 的 percpu 信息 ， 结 果 放 在 struct pcpu_alloc info 结构 中 */ 
ai = pcpu build alloc info(reserved size, dyn size, atom size, 


cpu distance fn); 


// 静 态 定 义 变量 占用 空间 +reserved 空间 + 动态 分 配 空间 


size sum = ai->static size + ai->reserved size + ai->dyn size; 


/* 针 对 每 个 group 操作 */ 

for (group = 0; group < ai->nr groups; group++) { 
struct pcpu group info *gi 一 &ai->groups [group]7 
unsigned int cpu = NR CPUS; 
void *ptr; 


/* 为 该 group 分 配 percpu 内 存 区 域 .长 度 为 处 理 器 数目 x 每 颗 处 理 器 的 percpu 递 进 
单位 。 函 数 pcpu_dfl fc alloc 是 从 bootmem 里 取得 内 存 ， 得 到 的 是 物理 内 存 */ 


ptr = alloc fn(cpu, gi->nr units * ai->unit_size，atom size); 


areas[group] = ptr; 
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base = min(ptr, base); 
// 为 每 颗 处 理 器 建立 其 percpu 区 域 
for (i = 0; i < gi->nr units; i++, ptr += ai->unit size) { 
if (gi->cpu map[i] == NR CPUS) { 
/* 检 查 组 内 处 理 器 ， 对 于 没有 用 到 的 处 理 器 释放 其 percpu 区 域 */ 
free fn(ptr, ai->unit size); 
continue; 
} 
/* 将 静态 定义 的 percpu 变量 拷贝 到 每 颗 处 理 器 percpu 区 域 */ 
memcpy (Ptr， _ per cpu load, ai->static size) 
/* 为 每 颗 处 理 器 释放 掉 多 余 的 空间 ， 多 余 的 空间 是 指 ai->unit_size 减 去 静态 
定义 变量 占用 空间 +reserved 空间 + 动态 分 配 空间 */ 


free_fn(Ptr + size sum, ai->unit size - size sum); 


/* 处 理 器 架构 相关 的 计算 ， 对 于 CA9 双核 架构 ，ai->nr groups 为 1， 且 
ai->groups [group] .base offset 和 max _ distance 这 里 的 计算 结果 都 为 0*/ 
max distance = 0; 
for (group = 0; group < ai->nr groups; group++) { 
ai->groups[group] .base offset = areas [group] - base; 
max distance = max t(size t, max distance, 
ai->groups [group] .base offset); 


max distance += ai->unit size; 


// 建 立 可 动态 分 配 的 percpu 内 存 区 域 


rc = pcpu setup first chunk(ai, base); 


// 建 立 可 动态 分 配 的 percpu 内 存 区 域 
int _ init pcpu setup first chunk(const struct pcpu alloc _ info *ai, 
void *base addr) 


static char cpus buf[4096] _ initdata; 
static int smap[PERCPU DYNAMIC EARLY SLOTS] _ initdata; 
static int dmap[PERCPU DYNAMIC EARLY SLOTS] _ initdata; 


for (cpu = 0; cpu < nr cpu ids; cpu++) 
unit map[cpu] = UINT MAX; 
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pcpu first unit cpu = NR CPUS; 


/* 针 对 每 一 group 的 每 一 颗 处 理 器 ,对 于 双核 CR9， ai->nr_groups 值 为 0， gi->nr units 
值 为 2*/ 


for (group = 0, unit = 0; group < ai->nr groups; group++, unit += i) 
const struct pcpu group info *gi = &ai->groups[group]; 


// 该 组 处 理 器 的 percpu 偏 移 量 ， 对 于 双核 CA9， 该 值 为 0 
group offsets[group] = gi->base offset; 
// 该 组 处 理 器 占用 的 虚拟 地 址 空间 


group_ sizes[group] = gi->nr units * ai->unit size; 


// 针 对 组 内 的 每 颗 处 理 器 
for (i = 0; i < gi->nr units; i++) { 
cpu = gi->cpu map[i]; 
if (cpu == NR_CPUS) 


continue; 
unit map[cpu] = unit + i; 
// 计 算 每 颗 处 理 器 的 percpu 虚拟 空间 偏 移 量 
unit off[cpu] = gi->base offset + i * ai->unit size; 


} 


pcpu nr units = unit; 


// 记 录 下 全 局 参数 ， 留 在 pcpu_alloc 时 使 用 


pcpu nr groups = ai->nr groups; 


/* 
构建 pcpu_slot 数组 ， 不 同 size 的 chunk 挂 在 不 同 pcpu_slot 项 目 中 
wy 

Bepu nr slots = popu size to slot (pepu unit size) + 2; 


pcpu slot = alloc bootmem (pcpu nr slots * sizeof (pcpu_ slot [OTN 
// 初 始 化 pcpu_slot 数组 链 头 
kor {I = O07 1 < pepu nr slots; 14+) 
INIT LIST HEAD(&pcpu slot[i]); 


/* 
构建 静态 chunk 即 pcpu_reserved _chunk， 该 区 域 的 物理 内 存 以 及 虚拟 地 址 都 在 int 
_ init pcpu embed first chunk(.…) 里 分 配 了 
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*/ 
schunk = alloc bootmem(pcpu chunk struct size); 


schunk->immutable = true; 
/ /物理 内 存 已 经 分 配 ， 在 这 里 标志 
bitmap fill(schunk->populated, pcpu unit pages); 


if (ai->reserved size) { 
//reserved 的 空间 ， 在 指定 reserved 分 配 时 使 用 
schunk->free size = ai->reserved size; 
pcpu reserved chunk = schunk; 
// 定 义 的 静态 变量 的 空间 也 算 进 来 


pcpu reserved chunk limit = ai->static size + ai->reserved size; 


} else { 
schunk->free size = dyn size; 
dyn size = 0; /* dynamic area covered */ 


} 


schunk->contig hint = schunk->free size; 
schunk->map[schunk->map used++] = -ai->static size; 


if (schunk->free size) 
schunk->map [schunk->map_used++] = schunk->free size; 


/* 动态 分 配 空间 ， 这 里 构建 第 一 个 chunk， 该 chunk 是 第 一 次 步 进 静态 变量 空间 和 
reserved 空间 使 用 后 剩 下 的 */ 
if (dyn size) { 

dchunk = alloc bootmem(pcpu chunk struct size); 

INIT_ LIST HEAD(&dchunk->1ist); 


// 记 录 下 来 分 配 的 物理 页 
bitmap fill (dchunk->populated, pcpu unit pages); 


dchunk->contig hint = dchunk->free size = dyn size; 
/*map 指针 更 新 将 静态 变量 空间 和 reserved 空间 甩 在 后 面 */ 

dchunk->map [dchunk->map used++] = -pcpu reserved chunk limit; 
dchunk->map [dchunk->map used++] = dchunk->free size; 


/* 把 第 一 个 chunk 链接 进 对 应 的 slot 链表 ，reserved 的 空间 有 自己 单独 的 chunk: 
pcpu_ reserved chunk */ 
pcpu first chunk = dchunk ?: schunk; 


pcpu chunk relocate(pcpu first chunk, -1); 


/* we're done */ 
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pcpu base addr = base addr; 
return 0; 


$ 
1.2.3 ”Percpu 动态 分 配 内 存 空间 


关于 Percpu 动态 分 配 内 存 空 间 有 以 下 基本 概念 : 
(1) 每 颗 处 理 器 的 自己 Percpu 动态 分 配 内 存 空 间 都 有 不 同 的 虚拟 地 址 空间 ， 和 否则 同一 
线程 在 不 同 处 理 器 上 运行 时 修改 页 表 页 目录 项 的 开销 太 大 。 
(2) Chunk 记录 每 颗 处 理 器 一 次 步 进 得 到 虚拟 地 址 空间 ， 对 于 一 颗 处 理 器 来 说 一 次 步 
进 长 度 是 ai->unit size，Percpu 内 存 的 虚拟 地 址 以 Chunk 为 基础 。 
(3) Chunk 中 每 一 次 配 出 的 内 存 用 其 map[] 指 向 。 
(4) Chunk 根据 其 free 的 内 存 长 度 挂 到 Slot 数组 的 对 应 链表 上 。 
(5) 每 次 步 进 仅 得 到 虚拟 地 址 空间 ， 在 完成 一 次 分 配 时 才 得 到 对 应 的 物理 内 存 。 
本 书 仅 考虑 percpu-vm 的 情况 。 
/* 动 态 分 配 函数 */ 
static void _percpu *pcpu alloc(size t size, size t align, bool reserved) 
{ 
static int warn limit = 10; 
struct pcpu chunk *chunk; 
const char *err; 
int slot, off, new alloc; 
unsigned long Sy 


mutex lock(&pcpu alloc mutex); 


spin lock irqsave(&gpcpu lock, flags); 


/* 指定 reserved 分 配 ， 从 pcpu_reserved_chunk 进行 ， 较 简单 不 讨论 */ 


if (reserved && pcpu reserved chunk) { 
} 


restart: 
/* 根据 需要 分 配 内 存 块 的 大 小 索引 slot 数组 找到 对 应 链表 */ 
for (slot = pcpu size to slot(size); slot < pcpu nr slots; slot++) { 
list for each entry(chunk, &pcpu slot[slot], list) { 
// 在 该 链表 中 进一步 寻找 符合 尺寸 要 求 的 chunk 
if (size > chunk->contig hint) 
continue; 
/*chunk 用 数组 int*map 记录 每 次 分 配 的 内 存 块 ， 若 该 数组 用 完 〈 该 chunk 仍然 还 
有 自由 空间 )， 则 需要 增长 该 int *map 数组 */ 


new alloc = pcpu need to extend (Chunk) 
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if (new alloc) { 
spin unlock irqrestore (gpcpu lock, flags); 
// 扩 展 int *map 数组 
if (pcpu extend area map(chunk, 


new alloc) < 0) { 


L 
spin lock irqsave(&pcpu lock, flags); 
goto restart; 


} 
/* 在 该 chunk 里 分 配 虚拟 内 存 空 间 : 分 割 最 后 一 段 自由 空间 , 然后 重新 将 该 chunk 


挂 到 slot 数组 对 应 链表 中 */ 
off = pcpu alloc area(chunk, size, align); 
//off 大 于 0 表示 分 配 成 功 
if (off >= 0) 
goto area found; 


spin unlock irqrestore(gpcpu lock, flags); 
/* 创 建 一 个 新 的 chunk， 这 里 进行 的 是 虚拟 地 址 空间 的 分 配 */ 


chunk = pcpu create chunk(); 


spin lock irqsave(gpcpu lock, flags); 
// 把 一 个 全 新 的 chunk 挂 到 slot 数组 对 应 链表 中 
pcpu chunk_ relocate (chunk, -1); 


goto restart; 


area_ found: 
spin unlock irqrestore(gpcpu lock, flags); 


/* 一 次 percpu 内 存 分 配 成 功 ， 这 里 要 检查 该 段 区域 对 应 物理 页 是 否 已 经 分 配 ， 否 则 将 为 该 
区 域 分 配对 应 的 物理 页 并 作 填充 L1 L2 页 表 项 */ 
if (pcpu populate chunk(chunk, off, size)) { 


mutex unlock(gpcpu alloc mutex); 


/* return address relative to base address */ 


return _addr to pcpu ptr(chunk->base addr + off); 


第 1 章 ARM 多 核 处 理 器 13 


1.3 CpuFreq 


简单 来 说 ，CpuFreq 由 两 方面 组 成 ， 一 方面 是 调频 算法 ， 其 决定 如 何 调频 、 何 时 调频 、 
调频 还 是 Up 或 Down 处 理 器 ; 一 方面 是 具体 操作 由 其 实现 如 何 调频 。 其 实现 为 : 

(1) govemeor 监测 当前 系统 的 负载 情况 ， 即 为 调频 算法 。 

(2) 通过 cpufreq_driver 对 Arm core 外 围 的 时 钟 电路 、 供 电 电路 实施 操作 ， 达 到 调频 
的 作用 ， 即 为 调频 操作 。 

对 于 大 部 分 CA9 架构 处 理 器 ， 调 频 算法 都 是 运行 在 CPU0 上 , 通过 CPU0 来 对 其 他 调 
频 、Down 或 Up。 


1.3.1 初始 化 


CpuFreq 初始 化 的 工作 主要 有 以 下 两 个 。 

在 底层 将 处 理 器 具体 操作 函数 注册 到 static struct cpufreq_driver *cpufreq_driver 中 ， 以 
满足 处 理 器 具体 调频 操作 需要 。SOC 厂商 都 必须 在 struct cpufreq_driver 里 实现 自己 最 底层 
的 调频 例 程 。 


struct cpufreq driver { 
int (*init) (struct cpufreq policy *policy); 


int (*target) (struct cpufreq policy *policy, 
unsigned int target freqg, 
unsigned int relation); 


La 
其 中 最 重要 两 个 例 程 为 : 
int (*target) (struct cpufreq policy *policy, unsigned int 


target freq,，unsigned int relation);// 该 例 程 实现 具体 的 调频 操作 
“int (*init) (struct cpufreq policy *policy);// 该 例 程 初始 化 struct 


cpufreq policy 

在 较 高 级 的 处 理 器 系统 设备 抽象 层 ， 将 CpuFreq 驱动 static struct sysdev_driver 
cpufreq_sysdev_driver 注册 到 处 理 器 系统 设备 类 ， 以 匹配 初始 化 每 颗 处 理 器 的 调频 操作 。 

/* 


SOC 实现 的 BSP 里 都 要 通过 调用 int cpufreq register driver(struct cpufreq driver 
*driver_data) 向 CpuFreq 注册 自己 的 struct cpufreq _ driver， 这 将 产生 两 个 影响 : 


将 soc 相关 的 struct cpufreq driver 暴露 给 CpuFreq，governor 将 据 此 进行 调频 动作 
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触发 CPU 设备 驱动 struct sysdev _ driver cpufreq sysdev_driver 的 注册 
这 将 导致 对 每 一 个 CPU 执行 static int cpufreq adqd dev(struct sys_device*sys_ dev) 
进一步 触发 cpufreq driver->init 


对 于 CA9 架构 ， 该 函数 在 具体 的 底层 BSP 中 调用 ， 参 数 就 是 SOC 相关 的 具体 调频 操作 
*/ 
int cpufreq register driverl(struct cpufreq driver *driver data) 


{ 


/* 重 要 静态 变量 static struct cpufreq driver *cpufreq driver; 记 录 了 处 理 器 底 
层 相 关 的 调频 操作 */ 
cpufreq driver = driver data; 
/* 注 册 到 struct sysdev_class cpu_sysdev_class， 该 函数 会 依次 扫描 处 理 器 系统 设 
备 类 中 的 处 理 器 ， 并 为 其 调用 static struct sysdev driver 
cpufreq sysdev_driver 的 static int cpufreq add _ dev (.…) 函数 ， 从 而 导致 系统 
中 调频 机 制 的 建立 */ 
ret = sysdev driver register(&cpu_sysdev_class， 

&cpufreq sysdev driver); 


} 


1.3.2 ”CpuFreq 策略 的 建立 


对 于 单 颗 处 理 器 架构 这 里 很 好 理解 ,完成 处 理 器 的 struct cpufreq_policy 初始 化 及 struct 
cpufreq_governor 的 选择 即 可 。 但 是 对 于 多 核 处 理 器 来 说 ,这 里 隐藏 着 调频 算法 在 哪 颗 处 理 
器 上 执行 的 问题 。 


/* 该 函数 的 关键 是 创建 struct cpufreq_policy， 每 颗 CPU 初始 化 、wakeup 的 时 候 都 会 执行 
该 函数 ， 但 是 struct cpufreq_policy 只 在 CPU0 初始 化 时 创建 ， 后 续 CPU 在 自己 的 局 部 数据 
per_cpul(cpufreq cpu data, cpu); 里 将 索引 到 该 结构 */ 
static int cpufreq add _ dev (struct sys_device *sys_dev) 
{ 
/* 如 果 当 前 cpu 被 关闭 ， 其 不 属于 调频 范畴 */ 

if (cpu is_offline (cpu)) 

return 0; 

#ifdef CONFIG SMP 

/* 

对 于 CA9 架构 ， 在 CPU0 初始 化 时 创建 struct cpufreq policy, 并 且 其 余 处 理 器 的 将 共 
享 CPU0 创建 的 struct cpufreq policy 

其 余 CPU 初始 化 时 直接 索引 到 该 struct cpufreq policy, 直接 返回 

wh 

policy = cpufreq cpu get (cpu); 


#endif 
/*CPU0 执行 到 这 里 ,分 配 struct cpufreq policy 结构 */ 
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policy = kzalloc (sizeof (struct cpufreq policy), GFP KERNEL); 
if (!policy) 
goto nomem out; 
// 分 配 struct cpufreq policy 结构 覆盖 的 处 理 器 范围 
if (!alloc_cpumask var(&policy->cpus，GFP KERNEL) ) 


goto err free policy; 


//CPU0 找到 默认 的 GOVERNOR 
if (!found) 
policy->governor = CPUFREQ DEFAULT GOVERNOR; 


/* 这 里 是 关键 ， 对 于 CA9 架构 多 核 处 理 器 ， 如 exynos4、imx6q， 这 里 都 把 struct 
cpufreq policy 的 cpumask var _t cpus 设置 为 所 有 的 处 理 器 。 这 里 的 原因 是 作为 SMP 
的 实现 ，CR9 每 个 CORE 的 频率 都 必须 保持 一 致 ， 一 次 调频 操作 对 所 有 的 CORE 都 有 相同 的 作 
用 。 这 在 之 后 的 static int cpufreq add dev_interface (..) 中 ， 所 有 在 线 处 理 器 的 
per_cpu(cpufreq_cpu data， j) 指针 都 指向 了 cPU0 创建 的 struct 
cpufreq_policy。 而 每 颗 处 理 器 的 per_cpu (cpufreq policy_cpu, j) 都 指向 了 CPU0 
*/ 

ret = cpufreq driver->init (policy); 


// 频 率 的 最 小 最 大 值 


policy->user policy.min = policy->min; 


policy->user policy.max = policy->max; 


ret = cpufreq add dev interface(cpu, policy, sys_dev); 


static int cpufreq add dev interface (unsigned int cpu, 
struct cpufreq policy *policy, 
struct sys_device *sys_dev) 


/* 体 现 SMP 架构 调频 特性 的 操作 ， 所 有 处 理 器 协同 调频 步调 一 致 */ 
for_each_cpu(j]，Ppolicy->cpus) { 
if (!cpu online(j)) 
continue; 
per_cpul(cpufreq cpu data, j) = policy; 
per_cpul(cpufreq policy cpu, j) = policy->cpu; 
} 


/* 这 里 发 送 的 CPUFREQ_GOV_START 通知 将 导致 处 理 器 调频 算法 的 启动 */ 


ret = cpufreq set policy(policy, &new policy); 
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1.3.3 Ondemand 调频 算法 分 析 


所 谓 处 理 器 调频 算法 struct cpufreq_governor 没有 准确 的 标准 ， 适 合 的 就 是 最 好 的 ， 系 
统 中 提供 了 若干 调频 算法 。 本 文 仅 选择 struct cpufreq_governor cpufreq gov_ondemand 分 析 ， 
这 个 算法 的 基本 做 法 是 启动 一 个 定时 器 ， 定 时 检查 系统 负载 ， 然 后 做 出 升降 频率 的 决定 。 

首先 CPUFREQ_GOV_START 消息 被 struct cpufreq governor cpufreq gov_ondemand 
截获 : 

static int cpufreq governor dbs (struct cpufreq policy *policy, 


unsigned int event) 


switch (event) { 
// 截 获 CPUFREQ GOV_START 消息 
case CPUFREQ GOV_START: 


// 定 时 器 初始 化 
dbs timer init(this dbs info); 


break; 


} 
启动 定时 器 来 检测 系统 负载 : 
static inline void dbs timer init (struct cpu dbs _ info s *dbs info) 


/* 定 时 器 函数 static void do _dbs _ timer (struct work struct *work) 是 检测 系统 
负载 的 重要 机 构 */ 
INIT_ DELAYED WORK DEFERRABLE (&dbs info->work, do _ dbs timer) 
schedule delayed work on(dbs info->cpu, &dbs info->work, delay); 
有 


检查 系统 负载 来 决定 如 何 调频 : 


static void do dbs timer(struct work struct *work) 


{ 
/* 这 里 检查 系统 负载 ， 无 非 就 是 累加 各 个 处 理 器 的 idle 时 长 ， 与 系统 设置 做 比较 */ 
dbs_check cpuldbs info); 


// 调 频 


__ Cpufreq driver target (dbs info->cur policy, 
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dbs info->freq lo, CPUFREQ RELATION H); 


// 准 备 下 一 次 检测 


schedule delayed work on(cpu, &dbs info->work, delay); 


} 


在 处 理 器 实际 实现 中 , 有些 SOC 在 实现 中 通过 检查 诸如 总 线 忙碌 之 类 的 硬件 参数 以 及 
处 理 器 温度 来 决定 调频 操作 。 而 有 些 系统 为 了 节省 成 本 省 掉 PMIC， 调 频 框架 并 不 产生 实 
质 的 升降 频 操 作 。 

内 核 中 提供 的 调频 算法 一 般 只 作为 参考 。 根 据 SOC 实现 的 不 同 ， 几 乎 大 部 分 厂商 的 
BSP 都 有 自己 的 调频 算法 。 其 实现 各 有 不 同 ， 但 通常 情况 下 有 如 下 共性 。 

(1) 通过 调整 送 入 ARM Core 的 clock 频率 及 其 工作 电压 完成 处 理 器 的 频率 调整 。 通 
常 ， 升 频 ， 先 调 压 再 调频 ; 降 频 ， 先 调频 再 调 压 。 

(2) 某 些 处 理 器 可 以 保持 较 高 电压 的 情况 下 往 下 调频 ， 但 没有 一 种 处 理 器 可 以 在 较 低 
电压 下 往 高 调频 。 

(3) 电压 的 调整 针对 不 同 的 PMIC 进行 ， 不 同 的 PMIC 提供 不 同 的 regulator， 在 
drivers/regulator 目录 下 实现 不 同 PMIC 的 regulator 操作 。 

(4) 调频 前 后 ， 所 有 ONLINE 会 接 到 内 核 notify 通知 。 

(5) 对 于 SMP 处 理 器 ， 所 有 的 CORE 都 以 相同 的 频率 工作 ， 所 以 每 次 调频 都 是 对 当 
前 所 有 online 的 CORE 进行 操作 。 

涉及 调频 部 分 的 代码 是 SOC 厂商 的 敏感 信息 , 往往 开源 代码 中 并 不 公开 。 为 避免 法 律 
纠纷 ， 这 里 不 再 分 析 具 体 厂 家 实现 。 


1.4 CPUO bootup CPU1 


在 SMP 架构 中 ， 尽 管 每 颗 处 理 器 运行 时 所 属 的 地 位 都 一 样 : 一 样 的 调度 队列 、 一 样 
的 处 理 器 选择 策略 。 但 是 在 系统 引导 时 ， 这 些 处 理 器 的 地 位 是 不 同 的 。 占 有 主导 作用 的 是 
CPU0， 该 处 理 器 最 先 被 引导 ， 为 其 他 处 理 器 创建 运行 环境 之 后 ， 再 boot up 其 他 处 理 器 。 
本 节 以 双核 处 理 器 为 原型 分 析 ，CPU1 指 的 是 非 Booting 处 理 器 。 本 节 分 析 实 例 为 
Exynos4210 。 

CPU1 的 激活 时 机 有 以 下 情况 。 

(1) 冷 启动 CPU0 完成 初始 化 后 ， 叫 醒 CPU1。 

(2) 从 SUSPEND 状态 恢复 ， 类 似 冷 启动 。 

(3) CPUFREQ 监测 到 当前 负载 过 高 。 


1.4.1 CPUo 侧 策略 和 动作 


在 Bring up CPU1 的 过 程 中 ，CPUO 主要 有 两 方面 的 工作 。 
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(1) 从 CPU0 跨 入 start kernel 那 一 刻 起 , 任何 一 颗 ONLINE 的 处 理 器 在 任何 时 刻 内 必 
然 处 在 菜 一 进程 的 Context 空间 内 。 即 使 调度 队列 为 空 ， 也 必须 进入 Idle 进程 空间 。 所 以 ， 
在 Bring up 其 他 非 Booting CPU 之 前 ，CPUN0 需 为 其 准备 Idle 进程 的 Context。 

(2) CPU0 需要 控制 CPU1 的 电源 、 时 钟 等 硬件 开关 及 时 序 ， 引 导 CPU1 进入 内 核 
入 口 。 
当 CPUO 决定 wakeup CPU1 时 ，CPUO 执行 cpu_up。 
//CPU0 的 执行 路 线 
int _cpuinit _cpu_ up (unsigned int cpu) 


// Idle 指向 待 唤醒 处 理 器 调度 队列 中 的 线程 
if (!idle) { 


} else { 


// 为 即将 唤醒 的 处 理 器 准备 一 个 idle 线程 
init idle(idle, cpu); 
} 


// 把 cPU1 要 用 到 的 页 表 页 目录 准备 好 

pgd = pgd alloc(ginit mm); 

pmd = pmd offset (pgd + pgd index (PHYS OFFSET), PHYS OFFSET); 
*pmd = pmd((PHYS OFFSET & PGDIR MASK) | 


PMD TYPE SECT | PMD SECT AP WRITE); 
flush pmd entry (pmd); 
outer clean range(_ pal(pmd), pa(pmd + 1)); 


// 把 为 CPU1 准备 启动 的 参数 放 在 secondary_data 里 

secondary data.stack = task stack page (idle) + THREAD START SP; 
secondary data.pgdir = virt to phys (pgd); 

__cpuc flush dcache areal(l&secondary data, sizeof(secondary data)); 
outer clean range(_ palg&secondary data), _ pal(l&secondary data + 1)); 


// 叫 醒 CPU1 


ret = boot secondary(cpu, idle); 


return ret; 


} 


//CPU0 唤醒 CPU1 的 硬件 操作 


int _cpuinit boot secondary (unsigned int cpu, struct task struct *idle) 


{ 
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//CPU0 把 要 叫 醒 的 CPU 写 在 pen_ release 中 


pen release = cpu; 
cpuc flush dcache areal (void *) &pen release, sizeof (Pen_ release)); 


outer clean range( palg&pen release), _palg&pen release + 1)); 


/*CPU0 把 CPU1 的 电源 域 打开 ， 这 时 在 另 一 侧 ，CPU1 开始 启动 ，CPU1 跑 到 boot monitor 


中 。CPU1 将 在 boot monitor 等 待 */ 
if (!(_ raw readl(S5P ARM CORE1 STATUS) & SS5P CORE LOCAL PWR EN)) { 


__ raw writel (SS5P CORE LOCAL PWR EN, 
S5P_ARM CORE1 CONFIGURATION); 


timeout = 10; 


/* 等 待 检查 CPU1 是 否 完成 硬件 Reset， 并 跑 到 Bootrom 里 相应 位 置 */ 


while ((_ raw readl(S5P ARM CORE1_ STATUS) 
& S5P CORE LOCAL PWR EN) != S5P CORE LOCAL PWR EN) { 
if (timeout-- == 0) 
break; 
mdelay (1); 


/* CPU0 把 CPU1 启动 跳 转 地 址 告诉 寄存 器 CPU1_ BOOT_REG， 这 时 CPU1 还 没有 打开 MMU， 
放置 的 是 物理 地 址 ，CPU1 侧 将 查看 寄存 器 CPU1_BOOT _ REG。CPU1 不 走 BL1，CPU0 的 休眠 
唤醒 才 走 BL1*/ 

if (!_ raw_ readl(CPU1 BOOT REG) ) { 


//CPU1 出 了 Bootrom 后 的 地 址 
_ raw writel (BSYM(virt to phys(s5pv310_ secondary startup)), 


CPU1 BOOT REG); 
smp_cross_call(cpumask of (cpu)); 


} 
//CPU1 重新 设置 了 pen_release，CPU0 这 边 的 控制 工作 到 此 为 止 


i£ (pen release == =1) 
break; 


udelay (10); 


1.4.2 ”CPU1 侧 执 行路 线 
CPU1 通常 由 自己 电源 域 单独 供电 。 当 CPU1 的 电源 域 被 打开 后 ，CPU1 直接 以 CPUO 
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的 当前 频率 起 跳 ， 然 后 进入 处 理 器 的 片上 bootrom 里 ， 在 一 个 与 CPUO0 约定 的 寄存 器 里 查 
找 自己 的 启动 地 址 后 ， 再 从 这 个 约定 地 址 直接 进入 内 核 。 对 于 CA9， 这 个 进入 的 地 址 通常 
被 命名 为 函数 : xxx_secondary_ startup。 


// 非 Booting 处 理 器 入 口 地 址 
ENTRY (s5pv310_ secondary startup) 


pen: 


a 


/* 读 取 本 CPU 的 ID， 参见 DDI0388F_cortex a9 r2p2 trm.pdf*/ 
Mre pis 0 EO C0 TO 5 

And r0, r0, #15 

Adr r4, 1f 

Ldmia r4, {r5, r6} 

Su ta 工 生 二 5 

Add r6, r6, r4 

/* 查 看 pen_release 的 CPU ID 是 否 是 自己 的 ID*/ 

ldr E77 [rz6] 

cmp r7, r0 

bne pen 

/* pen_release 的 CPU ID 是 自己 的 ID， cpu_up() 在 叫 自己 */ 
b secondary_startup 


.long 
.long pen release 


// arch/arm/kernel/head.S 


ENTRY (secondary_startup) 


adr r4, _ secondary data 
/*r12 被 放 入 地 址 secondary_switched*/ 


ldmia EA rs, ET, El2} @ address to jump to after 

Bub Ta; EA ED @ mmu has been enabled 

ldr ra; Tz77 YA @ get secondary data.pgdir 

/* 执 行 完 proc init 函数 之 后 返回 到 enable_mmu 执行 */ 

adr lr, BSYM( enable mmu) @ return address 

/* _enable_mmu 执行 之 后 会 跳 到 r13 执行 。 这 里 r13 被 放 入 _ secondary_switched 
的 地 址 */ 

mov rl13, rl12 @ _ secondary switched address 


ARM( add pc, r10, #PROCINFO INITFUNC) @ initialise processor 
@ (return control reg) 

THUMB( add r12, r10, #PROCINFO INITFUNC ) 

THUMB( mov pc, rl12 ) 


ENDPROC (secondary_ startup) 


ENTRY(_ secondary switched) 


Ldr sp, [r7, #4] @ get secondary data.stack 
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mov fp, #0 

// 最 终 执行 secondary_start kernel 

b secondary start kernel 
ENDPROC( secondary switched) 


//__ secondary data 处 存放 的 内 容 
.type __secondary data, %object 
__ secondary data: 
.long 
.long secondary data 
-long _ secondary switched 
接 下 来 讨论 一 个 特殊 情况 ， 即 关闭 CPU1 失败 后 的 再 引导 。 这 种 情况 发 生 在 试图 关闭 
CPU1， 但 是 底层 关闭 操作 动作 失败 。 
//CPU1 关闭 的 最 后 一 步 
void _ ref cpu die (void) 


// 关 掉 CPU1， 最 底层 的 CPU1 关闭 操作 

platform cpu die (cpu) 

/* 关闭 失败 ， 但 是 这 时 又 不 能 直接 返回 Tdle， 需 要 重新 走 一 次 引导 流程 。 正 常情 况 下 CPU1 
的 wakeup 不 走 这 条 路 ， 只 有 在 Die 失败 时 才 走 这 里 */ 


_asm ("mov sp, %S0\n" 


" b secondary start kernel" 


: "r" (task stack page(current) + THREAD SIZE - 8)); 


1.5 ”CPUI1 的 关闭 


1.5.1 关闭 时 机 


在 运行 中 系统 根据 负载 或 者 电源 策略 而 改变 , 为 节省 电力 ,在 必要 时 关闭 非 Booting 处 
理 器 ， 而 作为 系统 中 坚持 到 最 后 的 Booting 处 理 器 ， 在 系统 Suspend 的 时 候 也 会 关闭 。 本 
节 仍 以 双核 处 理 器 为 分 析 原 型 ， 分 析 非 Booting 处 理 器 即 CPU1 的 关闭 时 机 。 

CPU1 关闭 时 机 有 以 下 两 个 情况 。 

(1) 在 CpuFreq 机 构 监测 到 当前 负载 过 低 时 ， 在 某 些 平台 实现 时 会 关闭 该 处 理 器 。 内 
核 负 载 检测 机 构 会 不 停 计算 系统 负载 ， 在 负载 降低 到 一 定 阔 值 之 后 ， 将 关闭 CPU1。 这 里 
值得 关注 两 个 问题 ， 首 先 ,在 某 些 SOC 实现 中 硬件 能 够 通过 监控 处 理 器 状态 、 总 线 繁忙 程 
度 来 判断 负载 情况 , 这 时 对 系统 负载 的 检测 就 不 需要 通过 内 核定 时 计算 负载 来 完成 ; 再 者 ， 
事实 上 在 负载 变化 时 是 先 调频 还 是 先 关 闭 、 打 开 处 理 器 , 每 种 SCO 厂商 采用 的 策略 都 不 一 
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样 。 对 于 核心 数目 较 多 的 处 理 器 笔者 认为 开关 优先 是 较 好 的 策略 ， 对 于 双核 处 理 器 调频 优 
先 更 为 合 

// 定 时 监测 系统 负载 

static void dbs check cpu(struct cpu dbs info s *this dbs info) 


{ 


// 平 均 负载 是 否 小 于 阔 什 
if (avg load < dbs tuners ins.down _ threshold) { 
if (policy->cur == policy->min) { 
/* 当前 活跃 处 理 器 较 多 ， 且 hotplug_out_avg_load 小 于 阔 值 */ 
if (num online cpus() > 1 && hotplug out avg load < 
dbs tuners ins.down threshold) { 
cpu_ down (1); 


(2) 在 进入 Suspend 时 ， 操 作 系 统 电 源 决策 机 构 如 Android 的 PowerManagement 机 制 
或 者 用 户 自身 ， 决 定 要 将 系统 休 眼 时 ，CPUI1 将 首先 被 关闭 。 
// 进 入 休眠 ， 该 函数 的 调用 来 自 操作 系统 层 的 触发 
static int suspend enter(suspend _ state t state) 
{ 
// 关 闭 非 booting 处 理 器 


error = disable nonboot cpus(); 


1.5.2 CPU1 关闭 操作 


CPUI1 的 关闭 由 两 方面 组 成 : 一 是 决策 机 构 ; 二 是 CPU1 本 身 。 其 关闭 过 程 也 分 为 以 
下 阶段 。 

(1) 决策 处 理 器 上 运行 的 决策 算法 决定 关闭 CPU1，CPU_DOWN _PREPARE 类 型 通知 
被 发 出 ， 导 致 cpu_active_bits 的 CPU1 对 应 位 被 清除 。 

(2) 将 static int _reftake_cpu_down(void *_param) 操 作 挂 到 CPU1 的 struct cpu_stopper 
中 ， 并 等 待 CPU1 完成 操作 。 

(3) CPU1 上 执行 static int ref take_cpu_down(void * param), 将 cpu_online bits 上 的 
CPU1 对 应 位 清除 ， 将 CPU1 上 中 断 转 移 走 ， 并 关闭 局 部 时 钟 中 断 ， 更 关键 的 是 将 系统 中 
所 有 线程 允许 运行 位 图 上 的 CPU1 位 清除 ;发 出 CPU _DYING 通知 ,导致 CPU1 的 wake_ list 
链表 上 线程 被 加 入 CPU1 运行 队列 〈 这 时 其 运行 位 图 已 经 去 除了 CPU1 对 应 位 )， 接 下 来 执 
行 static void migrate tasks(unsigned int dead_cpu)， 将 CPU1 上 线程 迁移 到 别 的 处 理 器 上 。 


第 1 章 ARM 多 核 处 理 器 25 


(4) CPU1 继续 运行 ，CPU1 上 将 只 剩 IDLE 线程 可 以 运行 。 决 策 处 理 器 继续 往 下 运行 
等 待 CPU1 上 调度 上 idle 线程 。 

(5) CPU1 进入 idle task， 在 CPUI1 侧 会 清除 CACHE 之 类 的 操作 ， 然 后 在 大 部 分 CA9 
的 实现 中 CPU1 都 会 写 入 与 决策 处 理 器 约定 的 某 个 寄存 器 ， 然 后 执行 WFI。 

(6) 决策 处 理 器 接 下 来 与 CPU1 约定 的 寄存 器 被 置 位 后 ， 关 闭 CPU1 电源 。 

接 下 来 分 析 上 述 动作 的 源 代 码 实 现 ， 首 先 看 每 个 CPU 的 struct cpu_stopper 结构 。 它 用 
来 处 理 该 CPU 被 关 掉 之 前 的 一 些 工 作 。 


struct cpu stopper { 


spinlock t lock; 

struct list head works; /* list of pending works */ 
struct task struct *thread; /* stopper thread */ 

bool enabled; /* is this stopper enabled? */ 


}; 
struct cpu_stopper 结构 的 成 员 变量 struct task_struct*thread; 执 行 的 函数 为 : 


static int cpu stopper thread(void *data) 


{ 
不 断 从 struct list_head works; 取 出 work 执行 


} 
在 被 关 掉 的 CPU1 的 cpu_stopper 线程 里 执行 的 函数 : 


static int _ref take cpu down(void * param) 


{ 


struct take cpu down param *param = param; 


// 把 这 个 CPU online 位 清 零 ， 并 关 掉 这 颗 CPU 的 中 断 和 时 钟 


err = _cpu disable(); 


// 发 出 CPU_DYING 通知 
cpu_notify(CPU_DYING | param->mod, param->hcpu); 


// 把 该 CPU 运行 队列 的 task 迁移 走 
if (task cpul(param->caller) == cpu) 
move task off dead cpul(cpu, param->caller); 


// 把 这 个 cPU 的 idle 线程 调度 起 来 
sched idle next(); 


return 0; 


// 在 被 关 掉 的 CPU 的 idle 函数 中 


void cpu idle(void) 
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#ifdef CONFIG HOTPLUG CPU 
// 这 颗 CPU 对 应 的 online 位 已 被 清 零 ， 所 以 这 颗 CPU 进入 cpu die () 
if (cpu is_offline (smp_processor id())) 
cpu die(); 
#endif 


} 


1.6 ARM 处 理 器 展望 


1.6.1 ARM 架构 处 理 器 的 演进 


ARM 公司 不 断 推 进 ARM 架构 处 理 器 的 演进 , 在 不 同时 期 有 着 不 同 代表 作 。 从 彪炳 史 
册 的 ARM7/9， 到 横 空 出 世 的 Cortex A8/9， 再 到 尚 处 研发 状态 的 64 位 V8 架构 处 理 器 。 每 
一 代 的 ARM 处 理 器 都 有 着 自己 的 历史 使 命 ，ARM 7/9 的 任务 是 开 疆 拓 土 ， 实 现 了 ARM 
的 普及 ，Cortex A8/9 完成 了 支撑 智能 手机 推翻 功能 机 的 革命 ，64 位 架构 目标 是 进军 服务 器 

然而 这 些 都 不 是 本 节 的 重点 ， 本 节 要 分 析 的 是 Cortex A7/A15 架构 处 理 器 。 此 处 理 器 
似乎 仅仅 是 CA8/9 的 补充 ， 没 有 明确 的 目标 。 但 是 Cortex A7/A15 身上 却 列 藏 至 今 尚未 被 
真正 释放 的 能 实现 系统 软件 架构 的 革命 。 


1. Cortex A15 


Cortex A15 主要 有 以 下 3 个 方面 的 改进 。 

(1) 硬件 支持 虚拟 化 

ARM 在 CA15 之 后 发 布 的 处 理 器 都 支持 硬件 虚拟 化 ，CA15 扩展 出 了 一 个 更 高 优先 级 
的 模式 ， 将 作为 hypervisor 的 kemel 和 user mode 都 运行 在 这 个 模式 ， 这 种 模式 下 提供 了 
PL2 的 IPA 到 PA 的 转换 以 及 VGIC。 这 样 可 以 由 Guest OS 内 核 自 主 处 理 自己 管辖 范围 内 
的 页 异常 ， 而 不 必 hypervisor 大 量 的 介入 。 笔 者 认为 这 是 处 理 器 虚拟 化 最 关键 的 地 方 ， 不 
然 大 量 的 页 异常 掉 到 hypervisor， 不 仅 性 能 受到 影响 ， 而 且 架构 上 也 是 畸形 的 。 

(2) 40 位 物理 地 址 

32 位 物理 地 址 的 问题 以 前 在 X86 体系 下 出 现 过 , 现在 又 开始 困扰 ARM 系统 了 。 感谢 
进程 间 虚 拟 地 址 隔离 ，4G 的 虚拟 地 址 仍 能 满足 进程 的 需求 ， 但 是 4GB 的 物理 内 存 很 快 达 
到 手机 、 平 板 的 极限 。40 位 物理 地 址 为 此 而 生 ， 这 样 可 以 把 任意 一 个 4G 的 虚拟 地 址 空间 
有 电 到 1024G 的 物理 内 存 的 任何 地 方 。 

(3) 流水 线 的 增加 和 Neon 流水 线 的 融合 

Cortex Al15 像 其 他 时 代 的 ARM 演进 一 样 ， 都 会 扩充 流水 线 的 ， 改 进 分 支 预测 等 ， 但 
是 值得 一 提 的 是 NEON 不 再 放 在 整数 流水 线 的 后 面 , 当 译 码 出 NEON 指 令 后 再 甩 给 NEON。 


第 1 章 ARM 多 核 处 理 器 27 


Al15 里 的 NEON 跟 其 他 的 流水 线 同 时 接受 调度 。 

从 Cortex A15 的 设计 可 看 到 PC 级 处 理 器 的 身影 , 更 复杂 的 逻辑 实现 带 来 更 高 的 性 能 。 
ARM 一 直 以 低 功 耗 著称 ， 而 Intel 的 处 理 器 则 反之 。 是 Intel 的 技术 不 如 ARM? 是 Intel 的 
工厂 比 不 过 Tsmc、SAMSUNG? 显然 都 不 是 。 原 因 在 于 : 对 高 性 能 的 追求 ， 必 然 要 用 到 更 
先进 的 处 理 器 设计 ，, 更 复杂 的 逻辑 ， 导 致 在 同样 工艺 水 平 下 Intel 处 理 器 占用 更 大 的 芯片 面 
积 ， 自 然 功 耗 就 上 来 了 。 当 Intel 忍痛 阁 割 掉 Medfiled 里 面 的 那些 先进 的 复杂 部 件 ， 自 然 
功 耗 降下 来 了 。 这 似乎 是 个 围城 , 为 了 追求 高 性 能 ， Al15 充分 体现 了 ARM 工程 师 的 智慧 ， 
然而 导致 了 芯片 复杂 度 的 升 高 ， 从 而 给 ARM 带 来 了 困扰 Intel 的 罩 梦 一 一 功 耗 。 

而 反观 mntel， 由 于 其 拥有 独步 天 下 的 半导体 工厂 ， 在 逐渐 改进 工艺 的 水 平 的 情况 下 ， 
可 以 使 用 更 多 复杂 运算 单元 而 保持 功 耗 不 变 或 下 降 。 而 ARM 就 玩 不 转 了 ， 因 为 ARM 的 
投 片 工厂 可 能 是 台积电 、 三 星 、GlobalFoundries 等 大 厂 ， 但 也 有 可 能 是 一 些 工 艺 水 平 落后 
若干 代 的 小 三 。 所 以 ARM 的 逻辑 设计 必须 考虑 到 这 些 工厂 的 实现 能 力 ， 一 些 先进 复杂 运 
算 单元 是 无 法 及 时 在 其 处 理 器 设计 中 使 用 的 。 所 以 一 些 大 的 半导体 公司 ,干脆 直 接 重 新 设 
计 其 ARM 处 理 器 ， 然 后 在 使 用 台积电 等 大 厂 最 先进 的 工艺 来 生产 ， 这 似乎 起 到 了 些 较 好 
效果 比如 Qualcomm 的 Snapdragon。 但 是 笔者 以 为 ， 这 还 是 比 不 了 人 剑 合 一 的 Intel。 

但 是 ， 天 下 是 天 下 人 的 天 下 。ARM 阵营 有 着 高 效 、 低 成 本 的 特点 ， 不 仅 横行 移动 市 
场 而 且 大 有 谋取 PC、Server 的 趋势 。 


2. Cortex A7 与 Big.Little 


Cortex A7 与 CA15 共享 指令 集 ， 但 是 CA7 不 能 乱 序 执行 ， 性 能 比 CA8 略 低 ，CA7 似 
平 是 CA15 的 缩小 版 ， 其 Die Size 只 有 Al15 的 114，ARM 发 布 这 个 架构 处 理 器 的 目的 似乎 
是 直 奔 功 耗 而 来 。 除 了 可 以 作为 一 颗 单独 的 处 理 器 ，CA7 还 可 以 与 CA15 搭配 工作 ， 构 成 
big.little 架构 ， 这 个 架构 的 关键 如 下 。 

(1) 大 部 分 系统 运行 的 时 候 都 不 需要 太 多 处 理 器 能 力 ， 一 个 多 核 系统 的 大 部 分 时 间 都 
是 将 其 他 的 Core 关 掉 的 。 这 时 Cortex A7 就 能 满足 要 求 ， 可 以 把 耗 电 的 A15 关闭 掉 。 但 系 
统 遇 到 计算 压力 的 时 候 再 bring up A15， 以 实现 高 性 能 。 

(2) 由 于 Al15 与 A7 是 软件 完全 兼容 的 , 所 以 可 以 套用 内 核 现 有 SMP 支持 架构 而 不 需 
要 大 规模 改动 。 

如 果 指 令 集 相同 ， 在 不 修改 内 核 模型 的 情况 下 ， 不 只 是 A15 搭 A7，A9 搭 A5 也 是 一 
样 可 行 的 。 

于 其 小 巧 、 省 电 且 保持 相当 计算 能 力 的 特点 。 A7 已 成 为 低 功 耗 及 价格 敏感 市 场 的 新 
兴 力 量 ，MTK 以 及 几乎 所 有 的 大 陆 手机 处 理 器 厂商 在 近 几 年 的 主力 产品 都 使 用 多 核 A7。 
而 一 些 老牌 嵌入 式 厂商 也 将 A7 作为 计算 中 能 力 要 求 不 高 、 且 价格 敏感 市 场 的 主力 。 


1.6.2 TrustZone 


TrustZone 是 ARM 架构 的 安全 扩展 ， 在 ARM11 时 首先 出 现 ， 其 主要 思想 是 通过 将 处 
理 器 扩展 出 一 个 新 的 Security 特权 状态 以 完成 安全 性 相关 工作 。 但 是 尽管 安全 领域 的 市 场 
需求 强烈 而 迫切 ，TrustZone 自问 世 以 来 一 直 未 被 业界 广泛 接纳 。 其 原因 在 于 : 
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(1) TrustZone 要 求 在 Security 特权 状态 构建 一 个 全 新 的 包括 内 核 、 应 用 在 内 的 生态 系 
统 ， 而 这 个 生态 系统 一 直 没 有 成 长 起 来 。 

(2) 由 于 TrustZone 本 身 的 架构 问题 ， 导 致 在 其 上 实现 软件 体系 会 遭遇 如 下 问题 。 

@ 首先 ， 若 所 有 的 处 理 器 核心 全 进入 Security 特权 状态 ， 势 必修 改 当前 内 核 模型 ， 
Non-Security 状态 下 平滑 运行 的 状态 被 打 断 ， 而 所 有 的 Core 都 进入 Security 特权 状态 又 无 
必要 ，Security 特权 状态 下 的 主要 应 用 只 有 加 解密 算法 和 输入 。 若 只 有 一 个 处 理 器 进入 
Security 特权 状态 ， 架 构 体 系 上 又 不 够 完美 。 

@ 即使 不 考虑 架构 设计 和 运行 效率 ，Security 特权 状态 另外 一 个 麻烦 在 于 ， 当 在 
Security 特权 状态 的 某 个 Core 操作 外 设 时 ， 势 必 与 Non-Security 状态 下 的 系统 软件 冲突 ， 
这 与 虚拟 化 中 Guest 访问 非 虚拟 设备 的 问题 一 样 ， 后 面 再 详细 介绍 。 

@ 另外 ，TrustZone 机 制 的 一 个 基础 在 于 总 线 访问 时 外 设 依赖 其 当前 AXI 交易 的 安全 
位 来 做 出 如 何 响应 ， 但 是 往往 Security 特权 状态 需要 控制 的 外 设 王 设计 并 没有 这 个 考虑 。 

所 以 ， 尽 管 TrustZone 有 着 强烈 而 广泛 的 市 场 需求 ， 但 是 由 于 其 本 身 对 现 有 软件 体系 
发 起 的 挑战 ， 使 得 业界 不 得 不 另外 寻找 方式 以 解决 安全 问题 。 

其 实 从 某 种 角度 来 看 ，TrustZone 的 Security 与 NON-Security 模式 更 适合 虚拟 化 架构 ， 
在 安全 模式 可 以 使 用 独立 的 页 表 页 目录 、 而 且 安 全 模式 下 也 有 对 应 于 非 安全 模式 下 的 7 种 
模式 , 类 似 于 Intel 的 处 理 器 虚拟 化 架构 的 Root 和 Guest 的 关系 。 这样 KVM 运行 在 安全 模 
式 下 还 能 保持 内 核 -SVC 与 用 户 -USR 的 架构 ， 非 常 完美 。 

兼容 是 处 理 器 演进 的 第 一 规律 ， 所 有 挑战 这 个 规律 的 处 理 器 都 是 找 死 ， 即 使 不 成 功 的 
处 理 器 设计 也 得 兼容 。 为 安全 架构 另外 再 设计 一 个 模式 ， 然 后 稍 加 修改 TrustZone 以 实现 
ARM 架构 完美 虚拟 化 。 但 是 ARM 没有 这 样 做 ， 而 是 选择 将 HYP 塞 在 PL1 的 下 面 ， 这 是 
一 个 尚 可 接受 但 并 不 完美 的 虚拟 化 架构 ， 也 许 是 这 个 规律 在 起 作用 。 注 意 ， 笔 者 是 说 
“也 许 ”。 


1.6.3 ARM Virtualization 


ARM 架构 在 CA15 以 后 发 布 的 A 系列 处 理 器 都 支持 虚拟 化 扩展 。 在 这 种 体系 下 实现 
虚拟 化 有 多 种 方案 可 以 选择 ， 尽 管 所 有 的 方案 理论 上 都 可 行 , 做 DEMO 工程 没有 问题 ， 但 
是 如 果 能 够 产品 化 ， 笔 者 认为 只 有 KVM 更 适合 ARM 虚拟 化 体系 ， 其 原因 如 下 。 

(1) 在 一 个 没有 虚拟 化 IO 支持 的 硬件 架构 上 ， 由 于 坚持 使 用 独立 的 Hypervisor， 嵌 入 
式 虚 拟 化 的 实现 不 得 不 允许 Guest OS 直接 访问 硬件 设备 。 由 此 带 来 诸多 隐患 : 多 个 Guest 
OS 和 Hypervisor 陷入 硬件 访问 冲突 、 中 断 分 发 、DMA 控制 的 深渊 。 因 为 控制 外 设 不 是 仅 
仅 读 写 ， 还 要 考虑 到 其 休眠 唤醒 、 中 断 分 发 等 情况 。 比 如 Guest OS 自身 的 休眠 对 设备 的 影 
响 ， 设 备 的 休眠 与 电源 域 相 互 影响 ， 而 电源 域 包 括 多 个 设备 必然 在 HyperVisor 里 控制 ， 这 
自然 导致 与 其 他 Guest OS 相互 影响 。 可 见 由 于 需要 和 硬件 平台 过 度 耦 合 ， 难 以 扩展 ， 典 入 
式 虚拟 化 只 适合 硬件 复杂 度 较 小 的 硬件 平台 ， 或 者 只 使 用 部 分 功能 的 复杂 硬件 平台 。 

(2) 而 诸如 Xen 之 类 虚拟 化 方案 修改 Linux BSP 成 为 Domain0， 这 样 所 有 硬件 访问 都 
可 以 被 Domain0 接管 ， 理 论 上 是 可 行 的 。 但 是 笔者 认为 这 不 是 一 个 适合 ARM 虚拟 化 体系 
的 好 架构 。 而 且 Xen 架构 设计 之 初 是 为 了 适 配 没 有 硬件 支持 X86 处 理 器 , 在 有 着 硬件 支持 
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的 处 理 器 上 这 个 虚拟 化 架构 过 于 爱 肿 ， 使 得 简单 问题 复杂 化 。 

(3) 另外 ， 抛 开架 构 不 谈 ， 将 Linux BSP 改 成 Domain0 的 工程 量 也 不 可 同日 而 语 。 在 
CA8 以 后 ， ARM SOC 体系 已 经 不 再 像 ARM9 那么 简单 了 。SOC 构成 普遍 出 现 了 GPU、 
VPU 等 多 个 主 设备 ， 层 层 交 叉 互 联结 构 的 总 线 ， 独 立 而 又 相互 依赖 的 电源 域 、 时 钟 域 ， 层 
级 的 中 断 控制 器 与 多 核 情况 下 的 中 断 分 发 。 要 完美 实现 对 所 有 硬件 组 件 的 控制 势必 有 很 多 
验证 、 测 试 工程 量 。 

(4) 更 进一步 ， 还 存在 一 个 非 技 术 因 素 ， 在 于 ARM SOC 界 的 游戏 规则 发 生 改变 ， 半 
导体 厂商 不 再 像 以 前 一 样 公 开 SOC 中 所 有 硬件 信息 。 很 多 硬件 IP， 厂商 虽然 开源 了 BSP， 
但 是 却 没有 任何 资料 描述 ， 而 诸如 GPU 之 类 的 驱动 只 以 二 进 制 的 形式 发 布 。 这 使 得 Linux 
BSP 改 成 Domain0 成 为 非 原矿 而 不 能 为 的 事情 。 

所 以 ,笔者 认为 最 适合 ARM 的 虚拟 化 架构 是 KVM, 其 特点 在 于 能 够 遵循 现 有 以 Linux 
BSP 管理 硬件 的 游戏 规则 ; 避免 Guest OS 直接 访问 外 设 以 提高 移植 性 ， 可 以 采用 
Frontend+Backend 驱动 模型 ， 以 提高 其 性 能 。 

ARM KVM 的 实现 完全 符合 KVM 原 有 架构 ， 只 是 在 处 理 器 相关 部 分 与 ARM 虚拟 化 
扩展 做 了 适 配 。 其 实现 如 下 : 

(1)ARM 虚拟 化 扩展 出 的 Hyp 模 式 拥有 最 高 优先 权 PL2, 但 是 这 个 模式 下 仅 作 为 HOST 
与 Guest 切换 的 中 转 。 

(2) HOST Linux 工作 在 PLO 和 PL1 状态 下 ， 其 Context 被 保存 在 Hyp 的 stack 中 。 

(3) Guest Linux 工作 在 PLO 和 PL1 状态 下 ， 其 Context 被 保存 在 其 虚拟 处 理 器 相关 结 
构 中 。 

Hyp 模式 下 一 张 _kvm_hyp_vector 异常 表 是 ARM KVM 架构 适 配 的 核心 ， 搭 起 Host 
与 Guest 之 间 的 桥梁 。 


_kvm hyp_vector: 


-globl _ kvm hyp_vector 
W(b) hyp_reset 

W(b) hyp_undef 

W(b) hyp_svc 

W(b) hyp_pabt 

W(b) hyp_dabt 

W(b) hyp_hvc 

Ww(b) hyp_irq 

W(b) hyp_fiq 


根据 ARM KVM 的 设计 ，hyp_undef、hyp_svc、hyp_pabt、hyp_dabt 四 种 异常 目前 被 
认为 是 不 可 能 出 现在 Hyp 模式 的 ， 这 几 种 异常 向 量 都 被 定义 为 没有 意义 的 bad_exception。 


1. HVC 异常 
作为 两 侧 HVC 指令 异常 的 入 口 ，hyp_hvc 异常 向 量 是 Hyp 模式 下 最 重要 的 异常 向 量 : 


hyp_hvc: 
/*HVC 调用 通常 携带 参数 而 来 ， 这 里 先 将 其 保存 */ 
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Push tet EL 2 

/*HSR 寄存 器 里 记录 了 HVC 异常 的 产生 是 否 是 由 于 PL1 发 生 HVC 异常 调用 ， 这 里 读 取 HSR 
寄存 器 ， 并 检查 是 否 是 PL1 遇 到 了 HVC 指令 */ 

2 @ HSR 

lsr r0, rl, #HSR EC SHIFT 


cmp r0, #HSR EC HVC 


bne guest trap @ Not HVC instr. 

/* 

确认 是 PL1 遇 到 HVC 指令 ， 接 下 来 要 通过 检查 VMID 区 分 是 来 自 Host 还 是 Guest 的 调用 
*/ 


mrrc plS5, 6; 07 xr2, C2 

1L5E E26 

and 2 r2; $0xff£ 

cmp r2, #0 

/* 来 自 Guest 的 HVC 调用 将 跳 转 至 guest_trap*/ 

bne guest trap @ Guest called HVC 
/* 来 自 HOST 的 HVC 调用 走 到 这 里 */ 
host_switch to hyp: 

/* 弹 出 刚才 保存 的 HOST 送 下 来 参数 */ 

Bop {r0, rl, r2} 

/* 保 存 SPSR*/ 

push tir} 

mrs lr, SPSR 

push {1r} 

/*HOST 调用 kvm_call _hyp， 将 Hyp 里 的 调用 地 址 放 在 r0 里 ，struct kvm vcpu 指针 

放 在 fl 里 , 这 里 把 跳 转 地 址 放 入 1r，struct kvm_vcpu 指针 放 入 r0。 这 里 还 要 处 理 好 r2、 

r3， 以 备 将 来 之 需 */ 

mov lr, r0 

mov r0, rl 

HOW Trl; 2 

mov r2, r3 


/* 味 转 到 ”kvm_vcpu_run 准备 恢复 Guest*/ 


blx 1r @ Call the HYP function 

/* 从 Guest 返回 到 Host 的 最 后 步骤， 将 从 这 里 弹 到 PL1*/ 
pop {1r} 

msr SPSR csxf, lr 

pop {lr} 

/*Hyp 模式 遇 到 eret， 弹 到 PL1*/ 

eret 


/*Guest hvc 异常 走 到 这 里 */ 
guest trap: 
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/1/r0 存放 VCPU 的 Contex 的 指针 
load vcpu @ Load VCPU pointer to r0 
str rl, [vcpu，#VCPU HSR] 


/* 若 从 Guest 而 来 ， 除 了 HVC 调用 ， 还 可 能 是 MMU 转换 异常 ， 如 对 设备 寄存 器 地 址 的 访问 */ 
lsr rl, rl, #HSR EC SHIFT 

cmp rl, #HSR EC IABT 

mrceq blS: 4 LL CO CO 2 @ HIFAR 

beq 2f 

cmp rl, #HSR EC _DABT 

/* 不 是 转换 问题 ， 直 接 走 返回 路 径 */ 

bne 1f 

/* 接 下 来 读 取 Cp15 获取 必要 信息 ， 在 这 里 展开 ， 继 续 分 析 往 Host 的 跳 转 */ 


/* 记 录 下 是 HVC 调用 */ 
1: mov rl, #ARM EXCEPTION_HVC 
/*Host 的 跳 转 函数 */ 


b _ kvm vcpu return 


/* 到 这 里 ， 说 明 Hyp 对 Guest 产生 的 异常 感到 绝望 ， 最 有 可 能 是 Guest 内 核 里 的 时 指针 ， 交 
给 Guest 自己 了 断 */ 


4: pop {r0, rl1} @ Failed translation, return to guest 
mcrr Bl5, 0% r0; rly €1 @ 了 AR 
clrex 


pop {r0, rl, r2} 
eret 
接 下 来 分 析 Hyp 模式 中 对 Host 向 Guest 切换 的 支持 。 


/* 这 个 函数 脉络 很 清晰 ， 即 把 Host Context 压 栈 ， 恢 复 Vcpu，eret*/ 
ENTRY(__kvm vcpu run) 


/* 这 是 一 个 宏 把 Host Context 讨 栈 ， 值 得 注意 的 是 这 里 的 Context， 除 了 通用 寄存 器 、 状 
态 寄存 器 ， 还 有 CP15 里 的 相关 信息 */ 


save host regs 


/* 恢 复 vcpu 状态 */ 
restore guest regs 
clrex 
/* 弹 到 Guest*/ 
eret 
从 Guest 返回 Host 与 从 Host 恢复 Guest 类 似 ， 只 是 弹 向 Host 的 操作 不 是 在 这 里 进行 
的 ， 参 见 上 文 。 
/*Guest 向 Host 返回 ， 来 至 Guest 的 Hvc 异常 */ 


kvm vcpu return: 
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/* 保 存 Guest 的 Context*/ 


save guest regs 


/* 恢 复 Host 的 Context， 这 里 的 关键 是 栈 里 的 1r 并 不 是 Host 的 IF， 而 是 Host 切换 到 
Guest 之 前 的 下 一 条 地 址 ， 因 为 当时 Hyp 使 用 了 blx,， 而 不 是 向 Guest 向 Host 时 使 用 的 b。 
其 实 无 论 host、hyp、guest 本 身 就 是 一 个 线程 ， 至 此 弹 掉 vcpu， 接 着 之 前 的 栈 轨迹 ， 非 常 符合 
逻辑 */ 


restore host regs 


/* 返 回 到 ”kvm_vcpu_run 之 前 的 下 一 条 指令 */ 
bx lr @ return to IOCTL 


2. 中 断 与 快速 中 断 异常 
接 下 来 再 分 析 hyp 异常 表 的 另外 两 个 异常 处 理 。 


/* 中 断 异常 向 量 函 数 */ 
hyp_irqg: 
push {E0% tl; r2} 


/* 保 存 下 原因 ， 中 断 导 致 的 Guest Exit */ 
mov rl, #ARM EXCEPTION IRQ 


load vcpu @ Load VCPU pointer to r0 
/* 继 续 向 Host 返回 ， 与 hvc 异常 操作 一 样 */ 
b __ kvm vcpu return 
.align 
/# 快 速 中 断 异 常 处 理 ， 与 中 断 异 常 处 理 无 异 */ 
hyp_fiqg: 
b hyp fiq 


针对 ARM KVM 进行 再 深层 次 分 析 。Host Linux 并 没有 工作 在 Hyp 模式 下 , 而 逻辑 上 


Hyp 模式 就 好 比 一 扇 连接 HOST 世界 与 GUSET 世界 的 大 门 , 与 ARM 处 理 SE 与 NON-SE 
状态 切换 的 手法 如 出 一 禾 , 都 是 通过 异常 来 实现 .尽管 HOST 与 Guest 都 工作 在 PL0O 和 PL1， 
但 是 HOST 是 有 着 优先 级 特权 的 ， 正 是 这 扇 大 门将 ROOT 世界 和 Guest 世界 隔离 开 来 。 


Hyp 模式 下 的 所 有 工作 都 可 以 通过 处 理 器 硬件 扩展 来 实现 ， 这 样 处 理 器 模式 就 可 以 精 


简 掉 Hyp 模式 ， 但 是 ARM 选择 了 这 种 轻 量 级 方式 ，ARM 的 生存 哲学 又 一 次 体现 在 其 演 
进 道路 上 。 


ava i 
2 
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异常 ， 这 个 词 非常 形象 地 描述 了 诸如 中 断 、MMU 转换 、 系 统 调用 等 需要 内 核 介入 的 
情况 与 系统 运行 时 的 关系 。 系 统 的 绝 大 部 分 工作 时 间 应 该 是 属于 应 用 程序 的 ， 应 用 程序 运 
行 才 是 系统 工作 的 正常 情况 ， 内 核 介 入 的 时 候 都 属于 不 正常 状态 。 

操作 系统 设计 的 目的 是 为 了 运行 应 用 ， 无 论 内 核 再 强大 ， 它 在 系统 中 都 是 应 该 位 居 幕 
后 的 、 默 默 无 闻 的， 应 该 像 大 地 一 样 稳 稳 的 支撑 ， 而 不 用 过 多 的 关注 。 若 一 个 内 核 需要 时 
不 时 在 系统 中 展露 自己 ， 那 一 定 不 是 一 个 好 的 内 核 。 

ARM 处 理 器 设计 了 若干 种 模式 以 便 内 核 处 理 对 应 的 情况 ， 本 章 分 析 ARM Linux 对 异 
常 处 理 的 基本 框架 ， 并 着 重 分 析 与 虚拟 内 存 管理 密切 相关 的 数据 异常 以 及 影响 整个 内 核 机 
理 的 中 断 异常 。 

传统 ARM 体系 的 7 种 异常 类 型 如 下 。 

(1) 复位 异常 。 即 复位 ， 从 reset 异常 向 量 重新 执行 。 

(2) 数据 异常 。 即 访问 数据 时 由 于 数据 页 面 不 存在 或 者 页 表 项 没有 建立 等 原因 引起 的 
异常 。 

(3) 预 取 指 令 异 常 。 即 访问 处 理 器 取 指 令 时 由 于 代码 页 面 不 存在 或 者 页 表 项 没有 建立 
等 原因 引起 的 异常 。 

(4) 快速 中 断 请 求 异 常 。 快 速 中 断 Fiq。 

(5) 中 断 请 求 。 中 断 民 Q。 

(6) 软件 中 断 异 常 。 用 于 系统 调用 ， 即 SWI， 内 核 维护 一 张 系统 调用 表 , 一 旦 SWI 
陷入 内 核 ， 内 核 根据 系统 调用 号 索引 到 相应 API， 并 依据 用 户 态 送 下 来 的 参数 调用 相应 函 
数 API， 完 成 后 走 类 似 用 户 态 中 断 、 数 据 及 取 指 异常 的 路 径 返回 用 户 态 。 

(7) 未 定义 异常 。 


2.1 异常 向 量 表 


根据 ARM 处 理 规范 ，ARM 的 异常 向 量 表 可 以 位 于 0X0000 或 者 0XFFFF0000， 这 两 
个 位 置 处 理 器 可 以 任 选 实现 。 现 代 处 理 器 一 般 都 是 可 以 通过 软件 来 动态 选择 异常 向 量 表 的 
位 置 。 又 鉴于 大 部 分 SOC 实现 都 是 使 用 0XFFFF0000， 因 此 本 书 认为 0XFFFF0000 就 是 
ARM 异常 向 量 表 地 址 。 

在 Linux 内 核 中 , ARM Linux 的 异常 向 量 表 位 于 arch/arm/kemel/entry-armv.S 中 。 其 地 
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址 范围 为 _vectors_start 到 _vectors_end， 依 次 为 复位 异常 、 未 定义 指令 异常 、 软 件 中 断 异 
常 、 取 指令 异常 、 取 数据 异常 、 保 留 异常 、 中 断 异 常 、 快 速 中 断 异常 。 


-globl _ vectors start 
Vectors start: 
swi SYS ERRORO 
b Vector und + stubs offset 
ldr pc, .LCvswi + stubs offset 
b vector pabt + stubs offset 
b vector dabt + stubs offset 
b vector addrexcptn + stubs offset 
b vector irq + stubs offset 
b vector fiq + stubs offset 


-globl _ vectors end 


其 中 每 种 类 型 的 异常 都 会 跳 转 到 一 个 异常 处 理 代码 段 。 尽 管 异 常 种 类 很 多 ， 但 是 这 些 
异常 代码 段 的 实现 是 如 下 形式 : 


vector_stub XXX，XXX_MODE，4 // 调 用 宏 vector_stub， 其 中 XXX 为 某 种 异常 
/* 以 下 又 是 一 个 跳 转 表 ， 该 跳 转 表 描述 了 处 理 器 在 某 种 模式 下 发 生 该 种 异常 的 处 理 方式 ， 其 中 最 重 
要 的 是 usr 和 svc 模式 ， 因 为 Linux 系统 下 只 用 到 这 两 个 模式 。 而 ARM 只 有 7 种 模式 不 考虑 
CA15 的 Hypervisor 模式 ， 也 不 考虑 Trustzone 的 Monitor 模式 )， 但 是 该 跳 转 表 确 定 了 16 
项 ， 其 原因 在 于 状态 寄存 器 的 0 一 4 位 都 被 用 来 标记 处 理 器 模式 了 ， 所 以 为 了 防止 某 个 异常 的 出 现 
而 搞 的 内 核 不 知 所 措 ， 该 跳 转 表 被 定义 为 16 项 */ 


-long _ XXX usr @ 0 (USR 26 / USR 32) 
-long _ Xxx invalid @ 1 (FIQ 26 / FIQ 32) 
-long “XXX invalid @ 2 (IRQ 26 / IRQ 32) 
.long _ XXX svc @ 3 (SVC 26 / SVC 32) 
-long “XXX invalid @ 4 
-long _ XxX invalid @e 
-long “XXX invalid 名 下 
异常 处 理 宏 的 实现 如 下 : 


.macro vector stub, name, mode, correction=0 


-align 5 


Vector \name: 
-if \correction 
sub lr, lr, #\correction 


-endif 


/* 发 生 异 常 时 arm 会 把 cpsr 保存 在 spsr 里 , 所 以 检查 spsr 就 能 查 出 , 异常 发 生前 处 理 器 
的 模式 */ 


@ Save r0, lr <exception> (parent PC) and spsr <exception> 
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@ (parent CPSR) 

stmia Sy. {i0 Le} @ save r0，1r //Lr 存放 异常 发 生前 pc 的 值 ，r0 是 swi 
的 参数 

mrs lr, spsr // 取 出 spsr 的 内 容 到 1r 中 


str lr, [sp, #8] @ save spsr 


/* 不 管 是 从 什么 模式 进入 异常 的 ， 在 Linux 内 核 使 用 svc 模式 ， 所 以 将 处 理 器 的 状态 切换 到 
SVC 模式 */ 


@ Prepare for SVC32 mode. IRQs remain disabled. 
mrs r0，cpsr // 取 出 cpsr 的 内 容 

eor r0，Tr0， 坦 (\mode ^ SVC_MODE) // 置 为 SVC 

msr spsr_cxsf，r0 // 写 回 cpsr 


@ 

@ the branch table must immediately follow this code 

@ 

and lr，1lr，#0x0f // 取 出 异常 发 生前 cpsr 的 模式 状态 位 

mov r0, sp 

/* 根 据 模式 确定 跳 转 值 。 当 前 pc 值 作为 基 址 ，pc 的 值 为 下 一 条 指令 地 址 ， 所 以 跳 转 的 地 址 应 
该 是 紧 跟 当前 这 段 代码 的 一 个 地 址 数组 ， 即 上 问 提 到 16 个 跳 转 项 */ 

ldr 1r; [pc, 1r, 131 #2] 


movs be 1r @ branch to handler in SVC mode 
ENDPROC (vector_\name) 
-endm 


2.1.2 ”异常 表 的 构建 


以 上 定义 了 内 核 的 异常 向 量 表 和 对 应 的 处 理 函 数 ， 编 译 后 被 链接 到 内 核 Image， 但 是 
内 核 Image 被 加 载 到 物理 内 存 的 地 址 不 是 使 得 该 向 量 表 正 好 能 被 映射 到 虚拟 地 址 
0xffffto000， 所 以 内 核 还 需要 将 异常 向 量 表 搬 到 0xffftto000， 而 向 量 表 与 对 应 的 处 理 函 数 的 
跳 转 使 用 指令 B， 为 相对 跳 转 指令 ， 指 令 B 一 共 才 32 位 长 ， 除 去 B 的 编码 ， 留 给 携带 的 
偏 移 量 只 有 32M， 所 以 还 得 把 处 理 函 数 处 理 到 0xffH0000 附近 ， 且 偏 移 量 要 跟 链 接 里 的 相等 。 


1. 位 于 arch/arm/kernel/traps.c 


void _ init early trap_init(void) 

{ 

//SOC 使 用 的 异常 向 量 表 基地 址 可 认为 CONFIG _VECTORS_BASE=0XFFFF0000 
unsigned long vectors = CONFIG VECTORS BASE; 


extern char _ stubs start[], _ stubs end[]; 
extern char Vectors start[], vectors end[]; 
extern char _kuser helper start[], _ kuser helper end[]; 


int kuser sz = kuser helper end - _ kuser helper start; 
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/* 
* Copy the vectors, stubs and kuser helpers (in entry-armv-S) 
* into the Vector page, mapped at 0xffff0000, and ensure these 


* are visible to the instruction stream. 


*/ 
// 把 异常 向 量 表 移动 到 0XFFFF0000， ”vectors end - vectors_start 为 异常 向 量 表 
长 度 

memcpy ( (void *) vectors, _ vectors start, _ vectors end 一 


_ Vectors start); 


/* 把 这 些 vector_xxx 函数 及 .LCvswi 移动 到 0XFFFF0000+0x200 的 位 置 ，_ stubs_start 
为 vector_xxx 及 .LCvswi 函数 开始 位 置 ，_stubs_end 为 结束 位 置 */ 


memcpy((void *)vectors + 0x200, _ stubs start, _ stubs end - 


_ stubs start); 


// 有 代码 移动 ， 更 新 icache 


flush icache range (vectors, vectors + PAGE SIZE); 


" 


由 此 可 见 在 arch/arm/kemel/entry-armyv.S 准备 了 异常 向 量 表 及 其 跳 转 地 址 , 而 实际 工作 
时 还 需要 再 做 一 次 移动 ，0XFFFF0000 附近 才 是 它们 的 工作 地 点 。 


2. SMP 中 异常 的 初始 化 


对 于 SMP 系统 ， 发 生 异常 时 每 个 处 理 器 都 要 索引 到 自己 的 异常 表 ， 否 则 处 理 嚣 是 没 
法 工作 的 。 在 CPUN0 的 初始 化 函数 void _init early_trap_init(void) 已 经 建立 了 虚拟 地 址 与 异 
常 表 映射 ， 接 下 来 将 其 余 处 理 器 的 启动 过 程 中 CPUO 建立 的 那 套 页 表 页 目录 复制 过 来 这 样 
就 可 以 进行 异常 索引 了 。 

在 CPUN0 启动 过 程 中 ， 会 执行 int _cpuinit cpu_up(unsigned int cp 由。 下 面 代码 为 其 
余 CPU 复制 页 表 页 目录 : 

int _cpuinit _cpu up(unsigned int cpu) 


{ 


/*CPU0 复制 自己 的 页 表 页 目录 , 这 样 在 4.1.3 节 里 CPU0 为 自己 创建 的 异常 表 也 为 其 他 CPU 可 用 
了 */ 
pgd = pgd_ alloc(&init mm); 


secondary data.pgdir = virt to _phys (pgd) 


/* 
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* Now bring the CPU into our world. 
*/ 


ret = boot secondary(cpu, idle); 


} 


由 此 可 以 得 出 结论 : 在 一 个 SMP 系统 里 ， 在 CPU0 初始 化 异常 表 之 后 ， 所 有 其 他 的 
CPU 都 共享 这 个 异常 入 口 ， 地 址 都 一 致 。 


2.2 中 断 体 系 


2.2.1 Cortex A9 多 核 处 理 器 的 中 断 控 制 器 GIC 


在 CA9 以 前 , 每 种 SOC 的 中 断 控制 器 是 自己 实现 的 , 但 是 到 了 CA9 SMP 以 后 ,中断 
控制 器 成 为 ARM 规范 的 一 部 分 ， 各 家 的 处 理 器 都 遵循 ARM 中 断 控制 器 GIC 规范 
IHI0048A_gic_architecture_spec。 其 中 原因 在 于 ， 对 于 非 SMP 的 架构 ， 中 断 控 制 器 就 是 控 
制 中 断 的 功能 ， 完 成 中 断 的 记录 、ack、 屏 项 等 功能 即 可 ， 各 家 厂商 爱 怎么 玩 就 怎么 玩 。 但 
是 到 了 SMP 结构 下 ， 除 了 ack、 记 录 、 屏 蔽 之 外 ， 中 断 控制 器 还 面临 如 下 问题 。 

(1) 中 断 分 发 给 哪 颗 处 理 器 。 

(2) 处 理 器 间 通 信 如 何 实现 一 一 处 理 器 通信 本 质 上 就 是 一 种 中 断 。 

(3) 处 理 器 局 部 中 断 。 

ARM 提供 的 中 断 控制 器 GIC 就 是 解决 以 上 问题 ， 根 据 GIC 规范 ， 中 断 安排 如 下 〈 参 
见 IHIO0048A_gic_architecture_spec 的 Figure 2-1 GIC logical partitioning into Distributor and 
CPU interfaces )。 

(1) 32-1019 SPI 全 局 中 断 ， 可 指定 分 发 到 不 同 的 处 理 器 。 

(2) 16-31 PPP 处 理 器 局 部 中 断 ， 处 理 器 局 部 可 见 。 

(3) 0-15 SGI 软件 产生 中 断 ， 由 CPU 写 ICDSGIR 产生 ， 可 指定 分 发 到 不 同 的 处 
理 器 。 

GIC 本 身分 成 两 部 分 : 

(1) GIC 的 DIST 部 分 ， 这 部 分 是 所 有 CPU 公用 的 。 

(2) 每 颗 CPU 自己 CPU interface 部 分 ， 这 部 分 控制 寄存 器 地 址 ， 只 能 被 CPU 局 部 
可 见 ，ARM 推荐 各 SOC 厂商 将 该 地 址 实现 为 相同 位 置 。 

以 上 概念 在 GIC 描述 结构 struct gic_chip_data 中 得 到 体现 。 


struct gic chip data { 
unsigned int irq offset;  // 中 断 号 的 偏 移 量 
void ”percpu iomem **dist base; // 记 录 每 颗 CPU 访问 GIC Dist 的 基地 址 
void percpu ”iomem **cpu base; /* 记 录 每 颗 CPU 访问 GIC CPU interface 
的 基地 址 ， 每 颗 处 理 器 看 到 同样 的 地 方 ， 但 是 访问 的 却 是 不 同 的 寄存 器 */ 


unsigned int gic irqgs; 
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2.2.2 MT6577 的 中 断 体系 


MTK 与 Android 是 绝 配 。 在 智能 机 时 代 ， MTK 尽管 开始 走 了 段 弯 路 ， 但 是 很 快 拨 乱 
反正 。MTK 的 智能 机 时 代 策略 ， 与 其 功能 机 时 代 如 出 一 略 ， 这 与 其 市 场 定 位 有 关 。 

MTK 手机 处 理 器 的 技术 路 线 不 追求 最 快 , 但 一 定 会 在 市 场 需要 时 准时 出 现 ; 不 追求 最 
强 ， 但 一 定 能 流畅 运行 最 新 版 本 的 Android 系统 与 应 用 。 

MTK 的 公 板 ， 从 器 件 选 型 、 电 路 板 设 计 到 Android 系统 实现 ，MTK 亲 力 亲 为 ， 儿 平 
做 好 了 所 有 技术 上 的 工作 。MTK 的 参考 设计 总 是 能 做 到 与 大 陆 手机 产业 链 完美 匹配 , 着 力 
支持 手机 供应 链 中 最 常用 、 供 货 最 有 保障 器 件 和 外 设 ， 而 同一 种 功能 器 件 和 外 设 ， 进 行 多 
家 验证 ， 以 确保 整 机 商 供应 链 的 安全 。 由 此 ， 华 南 的 IC、 模 具 、LCD、SMT 等 产业 链 以 
MTK 马 首 是 瞻 ， 总 是 自觉 地 将 产品 与 MTK 公 板 的 兼容 性 作为 其 重要 工作 。 

本 节 分 析 MT6577 的 中 断 体 系 。MT6577 的 Datasheet 不 是 个 公开 的 文档 ,况且 该 文档 
里 也 并 没有 清晰 地 阐述 其 中 断 体系 的 结构 。 但 是 通过 U8836d 公开 的 代码 却 可 以 完整 地 分 
析出 MT6577 的 中 断 架构 。MT6577 的 中 断 体系 的 最 高 层 依然 遵循 GIC 规范 , 可 参见 ARM 
公司 release 相关 技术 文件 。MT6577 中 的 实现 可 参见 U8836d 公开 的 代码 中 的 文件 : 


//U8836D\mediatek\platform\mt6577\kernel\core\include\mach\mt6577 irq.c 


//16 个 软件 中 断 

#define NR GIC SGI 16 

//16 个 处 理 器 局 部 中 断 ， 在 mt6577 中 其 实 只 使 用 了 5 个 ， 从 第 27 号 开始 

#define NR GIC PPI 16 

//128 个 全 局 中 断 

#define MT6577_NR_SPI (128) 

#define NR MT6577 IRQ LINE (NR_GIC SGI + NR GIC PPI + MT6577 NR SPI) 


// 全 局 中 断 从 第 32 号 开始 

#define GIC PRIVATE SIGNRLS 3 

// 处 理 器 局 部 中 断 的 起 始 号 

#define GIC PPI OFFSET (wah) 

// 如 下 定义 了 5 个 处 理 器 局 部 中 断 

#define GIC PPI GLOBAL TIMER (GIC PPI OFFSET + 0) 
#define GIC PPI LEGACY FIQ (GIC PPI OFFSET + 1) 
#define GIC PPI PRIVATE TIMER (GIC PPI OFFSET + 2) 
#define GIC PPI WATCHDOG TIMER (GIC PPI OFFSET + 3) 


#define GIC PPI LEGACY IRQ (GIC PPI OFFSET + 4) 
然后 从 32 号 中 断 开始 定义 了 104 个 全 局 中 断 。 


#define MT6577_L2CCINTR_IRO_ID (GIC_PRIVATE SIGNALS + 0) 


#define MT6577_USBO_IRQ ID (GIC_ PRIVATE SIGNALS + 8) 
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#define MT6577_USB1 IRQ ID (GIC_ PRIVATE SIGNALS + 9) 
#define MT6577 EINT IRQ ID (GIC_PRIVATE SIGNALS + 96) 
#define MT6577 EINT DIRECT7 IRQ ID (GIC_PRIVATE SIGNALS + 104) 


以 上 中 断 体系 的 实现 是 通过 GIC 的 配置 来 完成 ， 而 GIC 的 配置 在 初始 化 过 程 中 完成 。 
GIC 初始 化 包括 DIST 的 初始 化 和 每 颗 CPU 自己 interface 的 初始 化 。 DIST 初始 化 由 CPUO 
完成 ， 然 后 CPU0 再 完成 自己 备份 的 interface 初始 化 。 在 CPU1 起 来 之 后 再 完成 CPU1 的 
相关 interface 初始 化 。 

CPUD 的 工作 代码 如 下 : 


void _init mt init irqg(void) 


{ 


//DIST 的 初始 化 


mt gic dist init(); 
//CPU0 的 interface 初始 化 


mt gic cpu init() 7 


static void mt gic dist init (void) 


{ 


unsigned int i; 

u32 cpumask = 1 << smp_processor id(); 
cpumask |= cpumask << 8; 

cpumask |= cpumask << 16; 


writel (0, GIC DIST BASE + GIC DIST CTRL); 


/* 
从 32 号 开始 ， 设 置 SPI 中 断 电 平 触发 ，N-N 模式 。GIC 从 GIC DIST_CONFIG --0xC00 
开始 是 中 断 分 发 寄存 器 ILCDICFR， 每 个 SPI 对 应 2 位 
% 
for (i = 32; i < (MT6577 NR SPI + 32); i += 16) { 
writel (0, GIC DIST BASE + GIC DIST CONFIG + i * 4 / 16); 


/* 
所 有 SPI 分 发 给 CPU0。 这 部 分 代码 只 有 CPU0 才能 执行 到 。GIC 从 GIC_DIST_TARGET 
--0x800 开始 是 中 断 分 发 寄存 器 ， 长 度 根据 支持 的 SPI 不 同 而 不 同 ， 每 个 中 断 对 应 8 位 ， 哪 

-位 置 1， 该 中 断 就 发 到 哪 颗 处 理 器 。Cpumask 每 8 位 的 最 低位 都 置 1， 所 以 从 32 号 中 断 开 
始 ，SPI 都 分 发 CPU0 
wy 
for (i = 32; i < (MT6577 NR SPI + 32); i += 4) { 

writel (cpumask, GIC DIST BASE + GIC DIST TARGET + i * 4/ 4); 
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/* 
GIC 从 GIC_DIST_PRI --0x400 开始 是 中 断 优先 级 寄存 器 ， 长 度 根据 支持 的 SPI 不 同 而 不 
同 ， 每 个 中 断 对 应 8 位 ， 这 里 把 所 有 SPI 优先 级 都 设置 为 相同 优先 级 
*) 
for (i = 32; i < NR MT6577 IRQ LINE; i += 4) { 
writel (OxAOAOAOAO0, GIC DIST BASE + GIC DIST PRI + i *4/ 4); 


/* 
GIC 从 GIC_DIST ENABLE CLEAR --0x180 开始 是 中 断 屏 蔽 寄存 器 ICDICER， 长 度 根据 
支持 的 SPI 不 同 而 不 同 ， 每 个 中 断 对 应 1 位 ， 置 1 屏蔽 该 中 断 
eh 
for (i = 32; i < NR MT6577 IRQ LINE; i += 32) { 

writel (OxFFFFFFFF, GIC DIST BASE + GIC DIST ENABLE CLEAR +i*4/ 32); 
. 
/* 
把 挂 到 Linux 中 断 描述 数组 里 去 ， 每 个 中 断 一 个 struct irq desc， 以 前 是 个 数组 ， 现 在 
可 选 成 radix 树 。 每 个 中 断 一 个 struct irq_desc， 记 录 两 个 中 断 处理 的 关键 数据 结构 
struct irq chip 和 irq flow handler 七 。 前 者 是 用 来 对 付 中 断 控制 器 ， 在 mt6577 
上 是 struct irq chip mt irq chip ， 后 者 是 中 断 处 理 程序 ， 分 成 void 
handle level irq(unsigned int irq，struct irq desc *desc)， 其 用 来 对 付 电 
平 触发 和 void handle edge irq(unsigned int irq, struct irqg desc *desc), 
其 用 来 对 付 边沿 触发 
*/ 
for (i = GIC PPI OFFSET; i < NR MT6577 IRQ LINE; i++) { 

irq set chip and handler(i, gmt irq chip, handle level irq); 

set irq flags(i, IRQF VALID | IRQF PROBE); 
} 

#ifdef CONFIG FIQ DEBUGGER 
irq set chip and handler (FIQ DBG SGI, &mt irq chip, 
handle level irq); 
set irq flags(FIQ DBG SGI, IRQF VALID | IRQF PROBE); 
#endif 


/* 
GIC 从 GIC_ICDISR --0x80 开始 是 中 断 屏蔽 寄存 器 ICDISR， 长 度 根据 支持 的 SPI 不 同 而 
不 同 ， 每 个 中 断 对 应 1 位 ， 置 0 表示 该 中 断 是 安全 中 断 ， 置 1 表示 该 中 断 是 非 安 全 中 断 ， 这 里 全 
置 1 
*/ 
for (i = 32; i < NR IRQS; i += 32) 
{ 
writel (OxFFFFFFFF, GIC ICDISR + 4 * (i / 32)); 
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/* 

ICDDCR 位 于 0x， 中 断 总 开关 打开 

*/ 

writel (3, GIC DIST BASE + GIC DIST CTRL); 
} 


// 该 函数 在 每 颗 CPU 被 激活 时 得 到 执行 
static void mt gic cpu init (void) 
{ 


Ln 主 


/* 

关闭 PPI, 打开 SGI。PPI 需要 用 到 时 调用 void mt_enable ppi (int irq) 打 开 , 在 u8836d 
系统 里 只 有 local timer 是 PPI 中 断 ， 在 其 初始 化 时 将 自己 对 应 使 能 位 打开 ，SGI 必须 全 
打开 ，SGI 用 来 做 处 理 器 间 中 断 的 基础 

*/ 

writel (0xffff0000, GIC DIST BASE + GIC DIST ENABLE CLEAR); 

writel (0x0000ffff, GIC DIST BASE + GIC DIST ENABLE SET); 


/* 设置 PPI SGI 中 断 优先 级 为 0x80*/ 
for (i = 0; 1<32; i += 4) 
writel (0x80808080, GIC DIST BASE + GIC DIST PRI + i *4/ 4); 


/* 设 置 PPI SGI 中 断 优 先 为 非 secure 中 断 */ 
writel (OxFFFFFFFF, GIC ICDISR); 


/* 操 作 自 己 的 CPU INTERFACE 的 ICCPMR 寄存 器 ， 只 有 优先 级 高 于 0xF0 的 中 断 才 会 送 入 
本 处 理 器 */ 
writel (0xF0，GIC_CPU BASE + GIC CPU PRIMASK); 


/* 操 作 自己 的 CPU INTERFACE 的 ICCICR 寄存 器 ， 做 如 下 设置 : 

(1) 允许 向 本 处 理 器 送 secure 中 断 

(2) 允许 向 本 处 理 器 送 非 secure 中 断 

(3) 把 secure 中 断送 到 本 处 理 器 的 FIQ 中 断 线 

(4) 中 断 抢 占 通过 secure binary point register 判断 

(5) 一 个 ICCIAR 的 secure 读 ， 导 致 非 secure 最 高 优先 级 pending 中 断 的 ack 
是 


writel (Ox1F, GIC CPU BASE + GIC CPU CTRL); 
dsb(); 
} 


值得 注意 的 是 MT6577 全 局 中 断 的 实现 又 分 为 两 种 。 
(1) 对 于 集成 在 SOC 里 的 外 设 ， 直 接 对 应 一 个 全 局 中 断 ， 如 MT6577_USB1_IRQ_ID， 
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在 其 驱动 初始 时 直接 将 其 中 断 处 理 函数 注册 到 内 核 的 中 断 处 理 里 数组 中 : 

request irq(nIrq, musbfsh->isr, IRQF TRIGGER LOW, dev name (dev), musbfsh) 
(2) 对 于 位 于 SCO 之 外 的 外 设 ， 则 通过 MT6577_EINT_IRQ ID 进行 转发 ，MT6577 
在 内 核 里 准备 了 一 个 外 设 中 断 处 理 函 数 的 数组 : 


typedef struct 
{ 
void (*eint func[EINT MAX CHANNEL]) (void); 
unsigned int eint auto umask[EINT MAX CHANNEL]; 
} eint func; 


这 些 外 设 通 过 void mt65xx_eint registration(...) 注 册 自 己 的 中 断 函 数 。 

比如 触 屏 控 制 器 gt813 ，mediatek\custom\out\huaqin77_cu ics2\kernel\touchpanel\ 
Gt813_driver.c 通过 该 函数 注册 自己 的 中 断 处 理 函 数 : 

mt65xx eint registration(**, tpd eint interrupt handler, 1); 

当 这 些 SOC 外 设 中 断 发 生 以 后 ，MT6577 将 在 GIC 的 MT6577_EINT IRQ_ID 上 产生 
中 断 ， 从 而 触发 其 中 断 处 理 函 数 static irqreturn _t mt65xx_eint isr(int irq, void *dev 1d)。 在 
该 函数 里 将 检查 eint_func 数组 ， 进 一 步 触发 对 应 的 处 理 函 数 。 


2.2.3 ”Exynos4 的 中 断 体系 


三 星 ，ARM 处 理 器 界 的 新 王者 ， 近 年 来 抢先 实现 每 一 代 ARM 处 理 器 ,而且 通过 手机 
处 理 器 与 其 庞大 硬件 产业 链 的 有 机 整合 成 为 Apple 的 最 有 力 对 手 。 

第 一 次 将 三 星 与 高 性 能 手机 处 理 器 联系 起 来 的 是 其 SSPV210， 和 凭借 超出 同 级 处 理 器 一 
倍 的 L2 Cache，S5PV210 成 为 当时 跑 得 最 快 的 CA8 ARM。 紧 接着 三 星 开始 抢 跑 ARM 界 ， 
在 CA9 时 期 ， 三 星 已 经 成 为 ARM 处 理 器 界 的 第 一 阵营 ， 在 CA15 时 期 三 星 成 为 第 一 家 先 
进 ARM 架构 的 实现 者 。 

三 星 的 ARM 处 理 器 成 功 背后 的 很 大 原因 在 于 三 星 强大 的 产业 链 整合 能 力 。 在 前 端 ， 
三 星 手机 的 攻 城 略 地 保证 了 三 星 处 理 器 出 货 量 。 在 后 端 ， 三 星 的 半导体 工厂 有 比肩 Intel 
的 能 力 ， 总 是 可 以 用 更 先进 的 工艺 来 降低 功 耗 ， 节 省 成 本 。 在 市 场 大 门 开 启 的 时 候 ， 三 星 
的 对 手 却 要 为 处 理 器 代 工 厂 的 工艺 和 良 率 伤 透 脑筋 ,为 炫 酷 的 LCD 屏幕 供 货 周 期 头疼 , 为 
了 内 存 和 EMMC 的 价格 波动 心 惊 胆 战 ， 而 所 有 这 些 ， 三 星 集 团 的 各 个 工厂 数 月 之 前 都 已 
经 协调 完毕 ， 正 按 计划 批量 出 货 了 。 


1. exynos4 的 中 断 体系 


CPUO 的 GIC 初始 化 工作 从 void _init exynos4_init irq(void) 开 始 。 


void _ init exynos4 init irq(void) 
{ 


int irqg; 


gic bank offset = soc is exynos4412() ? 0x4000 : 0x8000; 
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/*S5P VRA_GIC_DIST 是 CPU0 的 GIC DIST 基地 址 ，S5P_VA GIC CPU 是 CPU0 的 GIC CPU 
interface 基地 址 */ 
gic init(0, IRQ PPI MCT L, S5P VA GIC DIST, S5P VA GIC CPU); 


void _init gic init(unsigned int gic nr, unsigned int irq start, 
void _iomem *dist base, void _iomem *cpu base) 


struct gic chip data *gic; 


int cpu; 


//GIC 描述 结构 : struct gic chip data 
gic = &gic datalgic nr]; 

// 为 每 颗 CPU 分 配 放置 DIST 和 CPU interface 基地 址 的 内 存 地 址 
gic->dist base = alloc _percpu(void _ iomem *) 7 
gic->cpu _ base = alloc _percpu(void _ iomem *) 7 
// 先 初始 化 CPU0 的 DIST 和 CPU interface 基地 址 
for each _ possible cpul(cpu) { 

*per cpu ptr(gic->dist base, cpu) = dist base; 
*per_cpu ptr(gic->cpu base, cpu) = cpu base; 


gic->irq offset = (irq start - 1) & ~31; 


if (gic nr == 0) 
gic cpu base addr = cpu base; 


//DIST 的 初始 化 
gic dist init(gic, irq start); 
//CPU0 的 CPU interface 基地 址 的 内 存 


gic cpu init(gic); 


/* 所 谓 GIC dist 的 初始 化 ， 系 统 里 只 在 CPU0 进行 ， 核 心 工 作 是 配置 GIC SPI 中 断 (通常 外 围 
设备 产生 的 中 断 ) */ 
static void _init gic dist init(struct gic chip data *gic, 


unsigned int irq start) 


unsigned int gic irqs, irqg limit, i; 
void _iomem *base = gic data dist basel(gic); 


u32 cpumask = 1 << smp processor id(); 
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//cpumask: 每 个 8 位 的 最 低位 都 置 1 


cpumask |= cpumask << 8; 


cpumask |= cpumask << 16; 


writel relaxed(0, base + GIC DIST CTRL); 


/* 
* Find out how many interrupts are supported. 
* The GIC only supports up to 1020 interrupt sources. 
*/ 
gic irqs = read] relaxed(base + GIC DIST CTR) & Oxlf; 
gic irgs = (gic irgs 1) S323 
if (gic irgqs > 1020) 
gic irgqs = 1020; 


/* 
* Set all global interrupts to be level triggered, active low. 
*/ 

// 先 将 SPI 设置 为 电 平 触发 


for (i = 32; i < gic irqs; i += 16) 
writel relaxed(0, base + GIC DIST CONFIG + i * 4 / 16); 


/* 

* Set all global interrupts to this CPU only. 

Af 
/* 偏 移 量 0x800 一 0x81C 空间 的 每 个 BYTE 指出 了 对 应 的 中 断 分 发 到 哪 颗 CPU 上 ， 这 里 把 所 有 的 
全 局 中 断 的 分 发 方向 都 指向 自己 ， 这 时 只 有 CPU0 可 用 。 以 后 还 可 以 使 用 struct irq_chip 的 
int (*set affinity) (unsigned int irq,const struct cpumask *dest) ;函数 将 中 
断 绑 定 到 另外 的 CPU 上 */ 


for (i = 32; i < gic irqs; i 4) 
writel relaxed(cpumask, base + GIC DIST TARGET + i * 4 / 4); 


/* 
* Set priority on all global interrupts. 
*/ 

//0x400-0x7F8 


For. (i = 22 1 < dic irqsr 1 4= 
writel relaxed (0xa0a0a0a0, base + GIC DIST PRI + i * 4/ 4); 
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关闭 除 PPI 和 SGIs 之 外 的 中 断 
*/ 
for (i = 32; i < gic irqs; i += 32) 
writel relaxed (0xffffffff, base + GIC DIST ENABLE CLEAR +i*4/ 32); 


/* 
* Limit number of interrupts registered to the platform maximum 
*/ 
irq limit = gic->irq offset + gic irqs; 
if (WARN ON (irq limit > NR _IRQS)) 
irq limit = NR IRQS; 


/* 

* Setup the Linux IRQ subsystem. 

*/ 

// 填 充 linux 里 generic 中 断 分 发 数组 

for (i = irq start; i < irq_ limit; i++) { 
irq set chip and handler(i, &gic chip, handle fasteoi irq); 
irq set chip datal(li, gic); 
set irq flags(i, IRQF VALID | IRQF PROBE); 


writel relaxed(1l, base + GIC DIST CTRL); 


/*CPU0 的 GIC cpu interface 中 断 初始 化 ， 主 要 是 PPI 和 SGI 初始 化 ，SGI 是 处 理 器 间 通 信 
的 重要 手段 */ 
static void _cpuinit gic cpu init(struct gic chip data *gic) 
{ 
void _ iomem *dist base = gic data dist base(gic); 
void _ iomem *base = gic data cpu base(gic); 


Lot 3 


/* 
* Deal with the banked PPI and SGI interrupts - disable all 
* PPI interrupts, ensure all SGI interrupts are enabled. 
*/ 
// 值 得 注意 的 是 ， 这 里 PPI 中 断 是 被 屏蔽 的 
writel relaxed (Oxffff0000, dist base + GIC DIST ENABLE CLEAR); 
writel relaxed (0x0000ffff, dist base + GIC DIST ENABLE SET); 


/* 

* Set priority on PPI and SGI interrupts 
*/ 

for (i = 0; i < 32; i += 4) 
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writel relaxed(0xa0a0a0a0, dist base + GIC DIST PRI + i*4/ 4); 


writel relaxed(0xf0, base + GIC CPU PRIMASK); 
writel relaxed(1, base + GIC CPU CTRL); 


2. CPUX 相关 的 GIC 配置 


CPUX 不 需要 初始 化 GIC 的 SPI 中 断 , 所 以 CPUX 相关 的 GIC 初始 化 工作 完成 自身 的 
GIC cpu interface 中 断 初始 化 即 可 。 值 得 关注 是 其 执行 流程 : 


asmlinkage void cpuinit secondary start kernel (void) 
{0 
platform secondary init(cpu); 


0 


void _ cpuinit platform secondary init (unsigned int cpu) 


{ 
/* 显 然 对 于 Exynos4x12 处 理 器 ，CPUX 的 GIC DIST 和 CPU interface 基地 址 的 计算 是 : 
CPU0 的 对 应 基地 址 + 前 面 CPU 占用 的 长 度 */ 
void _ iomem *dist base = S5P VA GIC DIST + 
(gic bank offset * cpu); 
void _ iomem *cpu base = SS5P VA GIC CPU + 
(gic bank offset * cpu); 


gic secondary init base(0, dist base, cpu base); 


， 


void _ cpuinit gic secondary init base(unsigned int gic nr, 
void _ iomem *dist base, 
void _ iomem *cpu base) 
{ 
// 先 把 基地 址 放 到 GIC 描述 结构 里 的 数组 里 
if (dist base) 
* this cpu ptr(gic data[gic nr] .dist base) = dist base; 
if (cpu base) 
* this cpu ptr(gic data[gic nr] .cpu base) = cpu base; 
//CPUX 的 PPI SGI 中 断 初始 化 见 前 面 的 介绍 


gic cpu init(ggic datalgic nr]); 


2.2.4 OMAP4 的 中 断 体系 


尽管 已 经 宣布 退出 手机 市 场 ， 但 是 作为 移动 处 理 器 领域 的 领袖 ， Ti 在 相当 长 的 时 间 
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里 总 是 抢先 发 布 性 能 最 强 的 新 一 代 ARM 处 理 器 ， 而 且 早 期 还 会 搭配 其 强劲 的 DSP， 以 配 
合 ARM CORE 工作 。 尽 管 五 在 3G 时 代 遭 受 专利 困境 ， 但 是 凭借 其 强大 的 ARM 处 理 器 
设计 能 力 在 没有 Modem 的 情况 下 支撑 了 两 代 : Omap3 是 第 一 款 Cortex Ag8 产品 , 且 加 入 了 
C64+DSP， 当 时 的 性 能 在 业界 无 出 其 右 者 。 接 着 随 着 Neon 和 硬件 编 解 码 的 兴起 ，Omap4 
弱化 了 DSP 作用 ， 但 依然 领导 业界 进入 双核 时 代 。 

也 许 因 为 Omaps 的 功 耗 实在 不 能 满足 手机 需求 , 也 许 无 法 集成 Modem 弱化 了 Ti 的 竞 
争 力 ， 也 许 王 早已 决心 转身 模拟 ， 以 后 的 手机 处 理 器 将 不 会 有 Ti 的 身影 。Ti 将 Omaps 的 
积累 转化 成 其 戏 入 式 产品 keystonell, 但 是 嵌入 式 处 理 器 的 演进 由 于 其 市 场 需求 的 原因 , 将 
不 会 像 手 机 处 理 器 那样 精彩 。 

本 节 介绍 Omap4 中 断 体 系 。 


1. 初始 化 


void _init gic init irq(void) 


{ 


// 首 先 map 出 中 断 控制 器 Distributor 寄存 器 空间 

gic dist base addr = ioremap (OMAP44XX GIC DIST BASE, SZ 4K); 
BUG ON(!gic dist base addr); 

// 对 Distributor 的 初始 化 

gic dist init(0, gic dist base addr, 29); 


/* Static mapping, never released */ 


//map 出 中 断 控制 器 cpu interface 寄存 器 空间 


gic cpu base addr = ioremap (OMAP44XX GIC CPU BASE, Sz 512); 
BUG ON(!gic cpu base addr); 
gic cpu init(0, gic cpu base addr); 


/* 以 上 2 次 map， 实 际 上 就 是 在 页 表 中 建立 虚拟 地 址 到 物理 地 址 的 映射 。 这 个 动作 只 在 主 处 理 器 初 
始 化 时 进行 ， 而 在 第 二 颗 处 理 器 初始 化 时 并 未 进行 map 操作 。 其 原因 在 于 : 

(1) 第 二 颗 处 理 器 初始 化 过 程 中 上 拷贝 了 主 处 理 器 的 页 表 页 目录 。 

(2) 从 每 颗 处 理 器 往外 看 ，Distributor 系统 中 就 一 个 ， 其 物理 地 址 位 于 : 

#define OMAP44XX GIC DIST BASE 0x48241000 

虽然 cpu interface 每 个 处 理 器 都 有 自己 的 空间 ， 但 是 显然 在 Omap4 的 实现 中 将 其 做 成 了 相同 
的 物理 地 址 */ 

#define OMAP44XX_GIC_CPU_BRSE 0x48240100 


于 


void _cpuinit gic cpu init(unsigned int gic nr, void _iomem *base) 


{ 


48 


拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 
gic datalgic nr].cpu base = base; 


/* 初 始 化 CPU 中 断 控制 信息 ， 这 里 没有 显示 的 区 分 对 哪 颗 CPU 操作 ， 但 是 由 于 上 述 的 虚拟 地 址 的 
拷贝 关系 ， 哪 个 处 理 器 执行 到 这 里 就 对 哪 颗 处 理 器 操作 */ 

writel (0xf0, base + GIC _ CPU PRIMASK); 

writel (1, base + GIC CPU CTRL); 


void init gic dist init(unsigned int gic nr, void iomem *base, unsigned 
int irqg start) 


{ 


// 这 里 最 关键 的 是 记 下 Distributor 的 虚拟 地 址 
gic datalgic nr].dist base = base; 


} 
2. 第 二 颗 CPU interface 的 初始 化 


void _ cpuinit platform secondary init(unsigned int cpu) 
{ 


trace hardirqgs off(); 


// 初 始 化 该 cPU 中 断 控制 信息 


gic cpu init(0, gic cpu base addr); 


spin lock(&boot_ lock); 
spin unlock (gboot lock); 


3. CPU 间 中 断 发 射 


static inline void smp_ cross calll(const struct cpumask *mask) 


{ 


gic raise softirq(mask, 1); 
//mask 记录 了 要 向 哪些 处 理 器 发 射 中 断 ，irq 记录 要 产生 的 中 断 号 
#ifdef CONFIG SMP 
void gic raise softirq(const struct cpumask *mask, unsigned int irqg) 
{ 


unsigned long map = *cpus addr (*mask); 


/* this always happens on GIC0 */ 


第 2 章 异常 49 


/*Distributor 的 Software Generated Interrupt Register (ICDSGIR) 用 法 如 下 : 
第 16 位 一 一 第 23 位 : 目标 处 理 器 

第 0 位 一 第 4 位 : 中 断 号 

以 下 语句 向 mask 标记 的 CPU 发 射 irqg 号 中 断 */ 

writel (map << 16 | irq，gic data[0] .dist base + GIC DIST SOFTINT); 

} 

#endif 


23 中 断 处 理 


中 断 表 面 的 作用 是 作为 硬件 和 驱动 的 一 部 分 ， 把 中 断送 入 处 理 器 ， 激 活 中 断 handler 
以 响应 外 设 。 但 是 对 于 内 核 中 断 的 意义 远 非 这 些 ， 对 于 调度 器 ， 中 断 是 主要 激励 源 ， 中 断 
的 发 生意 味 着 可 能 的 线程 唤醒 ， 中 断 退 出 意味 着 可 能 的 线程 抢占 。 对 于 信号 机 制 ， 若 发 生 
在 用 户 态 ， 中 断 返 回 意味 着 信号 的 执行 。 对 于 多 核 处 理 器 中 断 是 其 处 理 器 问 交 流 的 手段 。 
本 书 把 中 断 在 内 核 其 他 机 制 的 分 析 放 在 其 相关 章节 ， 这 里 仅仅 分 析 中 断 本 身 。 


2.3.1 ”中断 的 基本 结构 
为 了 有 一 个 整体 的 印象 ， 先 来 分 析 中 断 基本 结构 ， 以 内 核 模式 发 生 中 断 为 背景 。 首 先 
中 断 异 常 代码 识别 是 USER 模式 还 是 内 核 模式 ， 如 果 是 内 核 模式 发 生 的 中 断 ， 则 跳 入 


__irq_sVc: 


__irq_svc: 
svc_entry // 中 断 进 入 

#ifdef CONFIG PREEMPT // 抢 占 维护 工作 
// 得 到 thread_ info 指针 
get thread info tsk 
/* preempt_count 的 最 低 8 位 记录 着 是 否 可 以 线程 抢占 ， 中 断 发 生 时 可 以 发 生 中 断 嵌 套 ， 
更 高 优先 级 中 断 抢占 当前 级 别 的 中 断 。 但 是 新 唤醒 的 线程 却 不 能 在 当前 中 断 处理 过 程 中 抢占 中 
断 handler。 因 为 当前 中 断 借用 当前 线程 的 内 核 栈 ， 优 先 级 是 针对 线程 而 言 的 ， 即 使 新 唤醒 
的 线程 优先 级 较 高 也 是 比 这 个 当前 线程 高 ， 并 不 能 说 明 比 中 断 本 身高 。 再 者 线程 抢占 中 断 是 没 
有 意义 的 。 若 对 实时 性 要 求 的 确 很 高 ， 可 以 把 中 断 处 理 线程 化 ， 中 断 唤醒 线程 化 的 handler 
后 即 退出 ， 让 线程 去 抢占 线程 */ 


ldr r8, [tsk, #TI PREEMPT] @ get preempt count 
add r7, r8, #1 @ increment it 
str r7, [tsk, #TI PREEMPT] 

#endif 


irq handler // 中 断 分 发 
#ifdef CONFIG PREEMPT// 抢 占 维护 工作 
// 本 次 中 断 退 出 ， 恢 复 抢占 计数 
str r8, [tsk, #TI PREEMPT] @ restore preempt count 
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ldr r0, [tsk, #TI FLAGS] @ get flags 
teq r8, #0 @ if preempt count != 0 
movne r0, #0 @ force flags to 0 


// 更 高 优先 级 的 线程 被 唤醒 ， 若 当前 线程 被 抢占 
tst r0, # TIF NEED RESCHED 


blne svc preempt 


#endif 
ldr r4, [sp, #5S_PSR] @ irqs are already disabled 
// 中 断 退 出 
SVC_exit r4 @ return from exception 


UNWIND (. fnend 二 
ENDPROC(_ irq svc) 


svc_entry 是 一 个 宏 ， 用 于 SVC 模式 中 断 进 入 ， 主 要 是 完成 寄存 器 保护 的 工作 : 


-macro svc entry, stack hole=0 


// 把 内 核 栈 的 指针 拉 下 来 ， 为 存放 寄存 器 留 出 空间 
sub sp, sp, #(S_FRAME SIZE + \stack hole - 4) 


// 把 r1-r12 这 12 个 寄存 器 放 进 内 核 栈 
stmia sp, {rl - r12} 


-endm 


以 上 是 内 核 态 发 生 中 断 的 处 理 ， 对 于 用 户 态 发 生 中 断 ， 最 大 区 别 是 在 返回 会 检查 是 否 
有 signal 要 处 理 。 接 下 来 继续 看 中 断 如 何 进 入 中 断 handler。 
中 断 handler 的 入 口 也 是 一 个 宏 定义 : 


-macro irq handler 


arch irq handler default 
9997: 
-endm 


arch irq handler default 的 实现 位 于 <asmentry-macro-multiS> ， 在 文件 
kernel/arch/arm/kernel/entry-armv.S 里 包含 了 该 文件 : 


-macro arch irq handler default 
// 把 GIC 基地 址 取出 来 放 到 r5 里 
get irqnr preamble r5, lr 
i: get irqgnr and base r0, r6, r5, lr 
movne po 
@ 
@ routine called with r0 = irq number, rl1 = struct pt regs * 
@ 
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adrne lr, BSYM(1b) 
/* 普 通 中 断 ， 分 发 */ 
bne asm do IRQ 


#ifdef CONFIG SMP 
// 检 查 是 否 是 IPI 中 断 ，IPI 中 断 是 SGI 类 型 ， 中 断 号 小 于 16 
ALT _SMP (test_for ipi r0, r6, r5, 1r) 
ALT UP B(9997f) 
//r1 存放 栈 指针 ， 跟 0 一 道 作为 参数 送 入 do_IPI 
movne Tl Bp 
adrne lr, BSYM(1b) 
/* 处 理 器 间 中 断 */ 
bne do_IPI 


#ifdef CONFIG LOCAL TIMERS 
// 检 查处 理 器 局 部 时 钟 ，29 号 
test for ltirq r0; r6; r5; lr 
movne r0, sp 
adrne lr, BSYM(1b) 
/*tick 中 断 */ 
bne do local timer 

#endif 


#endif 
9997: 
-endm 


2.3.2 中断 源 识别 


中 断 发 生 时 ， 首 先 要 确认 该 中 断 来 自 系 统 中 哪个 部 位 ， 这 就 是 中 断 源 识别 。 但 是 尽管 
中 断 控制 器 在 CA9 成 为 规范 , 但 是 每 种 架构 的 中 断 体系 都 不 一 样 ， 所 以 中 断 源 识别 在 每 种 
架构 下 的 实现 也 都 不 一 样 ， 本 节 以 exynos4 与 MT6577 为 例 分 析 中 断 源 识别 。 


1. exynos4 的 中 断 源 实 现 


// 代 码 位 置 : arch/arm/mach-exynos/include/mach/entry-macro.S 


-macro get irqnr preamble, base, tmp 
#ifdef CONFIG ARCH EXYNOS4 
mov \tmp, #0 
// 读 取 CP15 里 的 MPIDR 寄存 器 
mrc pl5, 0, \base, c0, c0, 5 
// MPIDR 的 最 低 2 位 指示 当前 读 取 动作 是 哪 蜂 CPU 所 为 ， 寄 存 器 base 里 就 是 处 理 器 号 
and \base, \base, #3 
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cmp \base, #0 

beq 1f 

ldr \tmp, =gic bank offset 
ldr \tmp, [\tmp] 

cmp \base, #1 

beq 1f 

cmp \base, #2 


//CPU2 
addeq \tmp, \tmp, \tmp 
//CPU3 
addne \tmp, \tmp, \tmp, LSL #1 
#endif 
1: ldr \base, =gic cpu base addr 


ldr \base, [\base] 


#ifdef CONFIG ARCH EXYNOS4 
add \base, \base, \tmp 
#endif 
-endm 
值得 注意 的 是 ， 该 版 本 的 代码 源 自 SAMSUNG 公开 的 其 i9300〈 四 核 处 理 器 版 本 ) 源 
码 包 ， 可 见 其 GIC 的 cpu interface 实现 没有 遵循 ARM 的 官方 推荐 一 每 颗 处 理 器 cpu 
interface 基地 址 都 不 一 样 。 而 对 于 kemel.org， 仅 支持 exy4210 (双核 版 本 )， 代 码 中 其 GIC 
的 cpu interface 实现 又 遵循 了 ARM 官方 的 推荐 一 一 每 颗 处 理 器 cpu interface 基地 址 都 一 样 。 


-macro get irqnr preamble, base, tmp 
// 直 接 取 基 地 址 ， 两 颗 处 理 器 得 到 的 地 址 都 一 样 
ldr \base, =gic cpu base addr 
ldr \base, [\base] 

.endm 


-macro get irqnr and base, irqnr, irqstat, base, tmp 


/*base 是 当前 CPU GIC interface 的 基地 址 ， 基 地 址 偏 移 #GIC_CPU_INTACK (0XC) 位 置 
的 寄存 器 是 Interrupt Acknowledge Register (ICCIAR)。 它 的 12 一 10 位 记录 了 如 果 是 
SGI 类 型 的 中 断 ， 产 生 该 中 断 的 CPU 号 。 第 0 一 9 位 记录 的 就 是 当前 中 断 号 */ 


ldr \irqstat, [\base, #GIC CPU INTACK] /* bits 12-10 = src CPU, 
9-0 = int # */ 


cmp \irqnr, #29 
cmpcc  \irqnr, \irqnr 
cmpne  \irqnr, \tmp 
cmpcs  \irqnr, \irqnr 


addne  \irqnr, \irqnr, #32 
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-endm 
2. MT6577 的 中 断 源 实现 


// 取 出 当前 处 理 器 gic intrface 的 基地 址 

-macro get irqnr preamble, base, tmp 
ldr \base, =GIC CPU BASE 

-endm 


-macro get irqnr and base, irqnr, irqstat, base, tmp 
// 取 ICCIAR 到 irqstat 
ldr \irqstat, [\base, #GIC CPU INTACK] /* bits 12-10 = src CPU, 9-0 = 


int # */ 

// NR_IRQS 是 mt6577 支持 的 最 高 中 断 号 16+16+128 
ldr \tmp, =NR_ IRQS 
// 将 ICCIAR 与 上 0x1c00 的 反 码 ， 取 9-0 位 到 irqnr 
bic \irqnr, \irqstat, #0x1lc00 


/* if (irqnr >= NR IRQS) return NO IRQ (0) */ 
cmp \irqnr, \tmp 

movcs \tmp, #0 

bcs BSYM(702f£) 


/* if (irqnr >= 32) return HAVE IRQ (1) */ 
cmp \irqnr, #(32) 

movcs \tmp, #1 

bcs BSYM(702f£) 


/* if (irqnr == FIQ DBG SGI) return HAVE IRQ (1) */ 
cmp \irqnr, #FIQ DBG SGI 

moveq \tmp, #1 

beq BSYM(702f) 


/* otherwise, return NO IRQ (0) */ 
mov \tmp, #0 


TO02: 

cmp \tmp, #0 

cmpeq \irqnr, \irqnr 
-endm 


/Vipi 类 型 的 中 断 检测 

-macro test for ipi, irqnr, irqstat, base, tmp 
// 取 出 中 断 号 放 在 irqnr 
bic \irqnr, \irqstat, #0xlc00 
// 用 中 断 号 减 16 
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cmp \irqnr, #16 

//c 清 零 ， 无 符号 数 小 于 ， 小 于 16 号 中 断 ， 为 SGI， 写 GIC，ack 该 中 断 

strcc \irqstat, [\base, #GIC CPU EOI] 

/*c 置 位 表示 无 符号 数 大 于 或 等 于 ， 则 不 属于 SGI 中 断 ， 若 小 于 16 号 中 断 ， 该 指令 不 执行 ， 
bne 条 件 成 立 ， 若 大 于 16 号 中 断 ， 该 指令 执行 ，bne 执行 条 件 不 满足 */ 

cmpcs \irqnr, \irqnr 
-endm 


// 检 测 是 否 是 lcoal timer 
.macro test for ltirq, irqnr, irqstat, base, tmp 
// 取 出 中 断 号 放 在 irqnr 
bic \irqnr, \irqstat, #0xlc00 
mov \tmp, #0 
//local timer 是 29 号 中 断 ， 比 较 
cmp \irqnr, #29 
moveq \tmp, #1 
/* 写 GIC 的 end of interrupt 寄存 器 ， 该 寄存 器 格式 要 求 cpuid 个 中 断 号 ，ack 该 中 断 ， 
与 icciar 一 样 ， 把 irqstat 回填 即 可 */ 
streq \irqstat, [\base, #6GIC CPU EOI] 
// 如 果 是 29，tmp 里 不 应 该 是 0 
cmp \tmp, #0 
.endm 


// 检 查 watchdog 中 断 
.macro test for wdtirq, irqnr, irqstat, base, tmp 
// 取 出 中 断 号 放 在 irqnr 
bic \irqnr, \irqstat, #0xlc00 
mov \tmp, #0 
cmp \irqnr, #30 
moveq \tmp, #1 
// 写 GIC 的 EOI，ack 该 中 断 
streq \irqstat, [\base, #GIC CPU EOI] 
cmp \tmp, #0 
.endm 


2.4 数据 异常 


数据 访问 异常 和 取 指 异常 ， 都 是 处 理 器 在 转换 数据 页 和 代码 页 时 遇 到 的 ， 是 虚拟 内 存 
机 制 的 上 层 触发 入 口 ， 两 者 工作 机 理 类 似 ， 本 节 以 数据 异常 为 例 展开 ， 为 下 一 章节 虚拟 内 
存 的 分 析 做 铺垫 。 

首先 再 次 审视 异常 向 量 表 中 数据 异常 相关 部 分 ， 这 是 数据 异常 的 内 核 入 口 : 

Vector stub dabt, ABT MODE, 8 
/* 用 户 态 发 生 的 异常 ， 比 如 程序 里 访问 某 个 变量 */ 
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-long _ dabt usr @ 0 (USR 26 / USR 32) 
.long _ dabt invalid @ 1 (FIQ 26 / FIQ 32) 
.long _ dabt invalid @ 2 (IRQ 26 / IRQ 32) 


/* 内 核 态 发 生 了 异常 。 内 核 态 正常 情况 下 不 可 能 发 生 这 个 异常 ， 除 非 是 遇 到 了 ex _table， 再 
者 就 是 BUG 了 */ 
.long _ dabt svc @ 3 {Svc 26 / SVC 32) 


另 一 方面 ， 内 核准 备 了 一 张 处 理 表 用 来 处 理 每 一 种 数据 异常 : 


static struct fsr info ifsr info[] = { 
do _bad, SIGBUS, 0, "unknown 0" Fi 
do _bad, SIGSEGV, SEGV ACCERR, "section access flag fault" 
] 
do_bad, SIGBUS, 0, "unknown 4" 和 
do translation fault, SIGSEGV, SEGV MAPERR, "section translation 
fault™ 本 
{ do _bad, SIGSEGV, SEGV_ACCERR, "page access flag fault"}, 
do page fault, SIGSEGV, SEGV_ MAPERR, "page translation fault"}, 
do_bad, SIGBUS, 0, "external abort on non-linefetch" }, 
{ do_bad, SIGSEGV, SEGV_ACCERR, "section domain fault"}, 
do_bad, SIGBUS, 0, "unknown 10" bs 
do_bad, SIGSEGV, SEGV_ACCERR, "page domain fault" 
{ do_bad, SIGBUS, 0, "external abort on translation" he 
do _ sect fault, SIGSEGV, SEGV_ACCERR, "section permission fault"}, 
do_bad, SIGBUS, 0, "external abort on translation" a 
do page fault, SIGSEGV, SEGV ACCERR, "page permission fault"}, 
do_bad, SIGBUS, 0, "unknown 31" bs 


Fs 


该 异常 表 窗 盖 了 ARM 处 理 器 可 能 发 生 的 所 有 的 数据 异常 ， 但 是 因为 ARM 的 有 些 机 
制 Linux 内 核 并 没 使 用 到 ， 所 以 对 于 这 类 异常 只 能 默认 使 用 do_bad， 这 将 导致 系统 panic。 
而 对 于 Linux 使 用 的 ARM 机 制 这 些 异常 都 有 对 应 的 处 理 函 数 。 数 据 异常 发 生 后 ， 无 论 用 
户 态 异常 还 是 内 核 态 异 常 ， 都 会 进入 到 内 核 的 数据 异常 处 理 函 数 中 : 

/* 该 函数 的 参数 addr 记录 了 异常 产生 的 虚拟 地 址 ， 参 数 fsr 记录 了 异常 产生 的 原因 */ 


asmlinkage void _exception 
do_DataAbort (unsigned long addr, unsigned int fsr, struct pt regs *regs) 


{ 


struct thread info *thread = current thread info(); 
/* 根 据 异 常 产 生 的 原因 索引 处 理 函 数 表 */ 

Const struct far info *inf = fer info + far fsa{(fsr}s 
int ret; 


struct siginfo info; 
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// 调 用 合适 的 异常 处 理 函 数 ， 如 果 返 回 非 零 ， 说 明 发 生 了 不 正常 的 异常 
if (!inf->fn(addr，fsr & ~FSR LNX PF, regs)) 


return; 


info.si signo = inf->sig; 

info.si errno = 0; 

info.si code = inf->code; 

info.si addr = (void _user *)addr; 

/* 如 果 是 用 户 态 发 生 的 不 正常 异常 ， 发 信号 杀 死 该 进程 ， 如 果 是 内 核 态 发 生 的 不 正常 异常 ， 
panic*/ 

arm notify die("", regs, &info, fsr, 0); 


} 
接 下 来 就 到 了 内 核 的 虚拟 内 存 处 理 ， 这 是 一 个 庞大 的 机 制 ， 影 响 到 系统 的 方方面面 ， 


将 在 本 书 的 其 他 章节 进行 分 析 。 


2.5 ”处 理 器 间 通 信 


处 理 器 间 通 信 的 基础 是 中 断 ， 在 CA9 架构 下 0 一 15 号 的 软件 触发 中 断 SGI。 在 GCI 


初始 化 的 时 候 各 处 理 器 开放 了 自己 的 0 一 15 中 断 ， 以 便 接 受 别 的 处 理 器 发 给 自己 的 中 断 。 
而 GIC 的 ICDSGIR 用 来 产生 SGI 中 断 ， 其 格式 如 下 : 


。 Bit 0 一 3 SGIINTID， 产 生 的 SGI 中 断 号 。 

e Bit 4 一 14 reserved。 

。 Bit 15 安全 位 ”0: 发 射 安全 中 断 1: 发 射 非 安全 中 断 。 

。 Bit 16 一 23 目标 处 理 器 位 图 每 颗 处 理 器 对 应 一 位 ， 置 1 将 向 该 处 理 器 发 射 SGI 
中 断 。 

。 Bit 24 一 25 ”00: 不 考虑 每 个 CPU interface 的 指示 来 发 射 中 断 ; 01 或 10: 根据 每 个 
CPU interface 的 指示 来 发 射 中 断 或 不 发 射 中 断 。 在 ARM Linux 系统 系统 系统 下 bit 
24 一 25 为 00。 


// 接 下 分 析 中 断代 码 分 析 整 理 自 基于 开源 手机 u8836q (mt6577) 笔记 


void irq_raise_softirq(const struct cpumask *mask, unsigned int irqg) 
{ 

unsigned long map = *cpus addr (*mask); 

int satt; 

u32 val; 
/* 
向 CPU1 发 射 IPI_CPU_START 中断， 是 CPU0 wakeup CPU1 的 最 后 一 个 动作 ， 这 里 如 果 检 测 到 
是 IPI_CPU_ START 中 断 ， 则 其 安全 位 被 置 为 secure 中 断 。 这 个 中 断 假 设 的 场景 是 CPU1 处 在 
WEI 状态 ， 发 射 该 中 断 使 其 继续 往 下 跑 ， 但 是 事实 上 这 个 中 断 的 并 没 起 到 必要 的 作用 。 当 CPU0 发 
射 这 个 中 断 时 CPUl 的 中 断 被 禁止 的 ，CPUL 直到 跑 到 void cpuiniit 
secondary start_kernel (void) 的 末尾 才 打 开 中 断 ， 这 里 并 不 是 WEI， 这 里 的 
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IPI_CPU_START 机 制 是 没有 意义 的 
*/ 


satt = (irq == IPI CPU START)? 0: (1 << 15); 
/* 从 dist 偏 移 量 0x80， 记录 了 每 个 中 断 的 secure 属性 , 每 个 中 断 对 应 1 位 , 置 0 表示 secure 
中 断 ， 置 1 表示 非 secure 中 断 ， 这 里 读 取 要 发 射 中 断 的 属性 信息 */ 

val = raw readl (GIC ICDISR + 4 * (irg / 32)); 

if (!(val & (1 << (irq $ 32)))) { /* secure interrupt? */ 

// 该 位 为 0，secure 中 断 

satt = 0; 

} 
/* 将 中 断 号 、 中 断 位 、 中 断 目标 一 并 写 入 ICDSGIR*/ 

_ raw writel((map << 16) | satt | irq, GIC DIST BASE + 0xf00); 


} 
内 核定 义 了 如 下 几 种 处 理 器 间 中 断 : 


enum ipi msg type { 

IPI CPU START = 1, 

IPT TIMER = 2, 
/* 这 是 最 常用 的 处 理 器 间 中 断 ， 被 调度 器 使 用 ， 它 用 来 通知 某 目标 处 理 器 ， 其 运行 队列 被 挂 入 若干 
task， 目 标 处 理 器 接 到 该 中 断后 ， 把 外 挂 队列 的 task active 到 自己 的 运行 队列 ， 有 具体 参见 调度 
器 一 节 */ 

IPI RESCHEDULE, 

IPI_CALL FUNC, 
/* 在 特定 目标 处 理 器 上 运行 某 特定 函数 ， 这 个 也 很 常用 ， 是 一 种 重要 的 内 核 机 制 ， 在 后 面 有 详细 介 
绍 */ 

IPI_CALL FUNC SINGLE, 

IPI_CPU_STOP, 

IPI_ CPU BACKTRACE, 
和 


以 IPL RESCHEDULE 为 例 分 析 IPI 发 送 过 程 : 
(1) 函数 指针 : static void (*smp_cross_call)(const struct cpumask *, unsigned int): 指 向 处 


理 器 间 通 信 的 发 射 函 数 ， 在 系统 初始 化 时 ， 将 该 指针 指向 该 平台 的 IPI 实现 函数 ， 对 于 
u8836d 自然 就 是 void irq_raise_softirq(const struct cpumask *mask, unsigned int irq)， 而 别 的 
CA9 SMP 架构 下 的 实现 与 函数 也 非常 相似 。 


(2) 当前 处 理 器 侧 ， 调 用 void smp_send reschedule(int cpu) 函 数 ， 其 中 cpu 是 目标 处 


(3) 目标 处 理 器 侧 产生 SGI 中 断 ， 导 致 函数 asmlinkage void _ exception irq entry 


do_IPI(int ipinr, struct pt_regs #regs) 被 调用 。 从 硬件 中 断 的 产生 到 该 函数 的 调用 参见 上 文 。 


// 其 中 ipinr 是 中 断 号 ，regs 与 普通 中 断 一 样 是 存储 的 寄存 器 状态 


asmlinkage void _exception irq entry do _IPI(int ipinr, struct pt regs 


*regs) 
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cpu)” 来 索引 ， 该 队列 上 每 一 个 节点 
待 该 处 理 器 执行 的 函数 。 
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/* 取 出 CPU 号 */ 

unsigned int cpu = smp processor id(); 

struct pt regs *old regs = set irq regs (regs); 

/* 中 断 状态 的 统计 ， 标 志 对 于 IPI 中 断 又 发 生 了 一 次 */ 

if (ipinr >= IPI CPU START && ipinr < IPI CPU START + NR IPI) 
_inc irq stat(cpu, ipi irqs[ipinr - IPI CPU START]); 


switch (ipinr) { 
case IPI CPU START: 
/* Wake up from WFI/WFE using SGI */ 


break; 


case IPI TIMER: 
_raw get cpu var(mt timer irqg) = IPI TIMER; 
ipi timer(); 
break; 
/* 目 标 处 理 器 接受 到 信息 */ 
Case IPI RESCHEDULE: 
/* 调 整 自己 的 运行 队列 */ 
scheduler ipi(); 
break; 


case IPI CALL FUNC: 
generic smp call function interrupt(); 
break; 
/* 目 标 侧 IPI_CALL_FUNC_SINGLE 响应 */ 
case IPI_CRLL_FUNC_SINGLE: 
generic smp call function single_interrupt() 
break; 


} 


IPI CALL FUNC SINGLE 
每 颗 处 理 器 都 有 一 个 struct call_ single_queue 队列 ， 队 列 由 “per_cpu(call single_queue, 
struct call single_data 都 有 一 个 函数 指针 指向 某 个 


当前 处 理 器 有 需要 某 特定 处 理 器 执行 函数 的 时 候 调 用 : 
/*cpu 为 目标 处 理 器 ，func 指向 目标 处 理 器 需要 执行 的 函数 ，info 为 参数 信息 wait 指出 是 否 
等 待 对 方 处 理 器 同步 */ 


int smp call function single (int cpu, smp call func t func, void *info, 
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int wait) 


struct call single data d= { 


-flags = 0, 
}; 
// 取 出 当前 cpu 


this cpu = get cpu(); 
// 如 果 目 标 处 理 器 就 是 自己 ， 就 不 要 折腾 了 ， 执 行 即 可 
if (cpu 一 this cpu) { 
local irq save (flags); 
func (info); 
local irq restore(flags); 
} else { 
/* 验 证 cpu 号 ， 验 证 该 cpu 是 否 在 线 */ 
if ((unsigned)cpu < nr cpu ids && cpu online(cpu)) { 
struct call single data *data = &d; 


if (!wait) 


data = & get cpu varl(csd data); 


// 将 该 struct call single data 的 flags 置 CSD_FLAG LOCK 
csd lock(data); 

// 设 置 目 标 处 理 器 位 ， 函 数 指针 信息 
cpumask set cpul(cpu, data->cpumask); 
data->func = func; 
data->info = info; 

// 执 行 
generic exec single(cpu, data, wait); 

} else { 
err = -ENXIO; /* CPU not online */ 


i 

/* 释 放 该 处 理 器 */ 
put_cpu(); 
return err; 


static 

int generic exec single(int cpu, struct call single data *data, int wait) 
{ 

// 这 里 的 cpu 是 目标 cpu， 索 引 目标 处 理 器 的 struct call single queue 队列 

struct call single queue *dst = &per cpul(call single queue, cpu); 
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// 关 中 断 ， 上 锁 ， 要 保证 这 个 链表 操作 不 被 打扰 

raw_ spin lock irqsave(&dst->lock, flags); 
ipi = list empty(&dst->list); 

list add tail (gdata->list, &dst->list); 
// 恢 复 中 断 ， 开 锁 


raw_ spin unlock irqrestore (&dst->lock，flags) 


// 发 送 IPI_CALL FUNC SINGLE 
if (ipi) 
arch send call function single ipi(cpu); 
/ /等待 ， 要 等 待 对 方 处 理 器 把 指定 函数 跑 完 
if (wait) 
err = csd lock wait(data); 
return err; 


/* 这 个 等 待 是 瞬间 完成 的 过 程 ， 没 有 休眠 */ 
static int csd lock wait(struct call single data *data) 
{ 
int cpu, nr online cpus = 0; 
/* 检 查 CSD_FLAG_LOCK 标志 是 否 被 对 方 清楚 ， 对 方 处 理 只 有 在 跑 完 指定 函数 后 才 会 清楚 这 个 标 
志 */ 
while (data->flags & CSD FLAG LOCK) { 
// 不 停 检查 在 线 处 理 器 个 数 
for each cpul(lcpu, data->cpumask) { 
if (cpu online(cpu)) { 
nr_online cpust+; 


} 
// 如 果 等 待 的 处 理 器 一 个 都 不 在 了 就 返回 
if (!nr_online_cpus) 
return -ENXIO; 
/ /等待 操作 


cpu relax(); 


return 0; 


目标 CPU 接 到 IPI_ CALL FUNC _SINGLE 后 调用 : 


void generic smp call function single interrupt (void) 
{  // 取 出 当前 struct call single queue 队列 
struct call single queue *q = & get cpu var(call _ single queue); 


unsigned int data flags; 


// 如 果 struct call single _ queue 队列 非 空 ， 说 明 有 活 要 干 
while (!list empty(&list)) { 
struct call single data *datas; 
// 依 次 取出 待 执行 的 函数 指针 
data = list entry(list.next, struct call single data, list); 
list del (gdata->list); 


data flags = data->flags; 
// 执 行 该 函数 


data->func (data->info); 


/* 

下 面 要 解锁 了 ， 对 方 处 理 器 还 得 等 待 呢 

*/ 

if (data flags & CSD FLAG LOCK) 
csd_ unlock (data); 


static void csd unlock(struct call single data *data) 


{ 


// 清 楚 CSD_FLAG_LOCK， 释 放 对 方 处 理 器 
data->flags &= ~CSD FLAG LOCK; 
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第 3 章 ”调度 与 实时 性 


3.1 Tick 


Tick 是 内 核 的 生命 脉搏 。 对 于 Fair 调度 类 和 RT 调度 类 中 的 SCHED_RR 线程 ，Tick 
的 每 次 到 来 将 意味 调度 实际 的 临近 。Tick 还 意味 当前 User 进程 Signal 的 处 理 时 机 。 对 于 处 
于 Sleep 状态 处 理 器 ， 在 满足 定时 Timer 的 基础 上 ， 则 需 消 除 不 必要 的 Tick。 


3.1.1 Localtimer 


Local timer 可 以 叫做 Ticker， 是 Tick 之 源 ， 是 处 理 器 局 部 的 。 其 产生 的 中 断 Tick 只 被 
对 应 处 理 器 处 理 。 

在 ARM CA9 架构 下 有 两 种 方式 的 Local timer。 

(1) SPI 类 型 的 Local timer。 将 中 断 分 发 给 对 应 的 处 理 器 即 可 ， 但 是 这 样 似乎 有 些 别扭 。 

(2) PPI 类 型 的 Local timer。 只 被 局 部 处 理 器 看 到 ， 不 占用 SPI 号 ， 自 然 和 谐 。 

CA9 早期 的 SOC 实现 主要 是 SPI 类 型 的 Local timer, 在 CA9 的 后 期 版 本 的 SOC 实现 
中 ， 以 PPI 类 型 Local timer 为 主流 。 

Local timer 的 具体 实现 与 处 理 器 相关 ， 以 Exynos4412 为 例 。 内核 里 每 颗 处 理 器 对 应 的 
Local timer 都 对 应 一 个 struct met_clock_event_device 的 实例 : 


struct mct_ clock event device mct tick[NR CPUS]; 


每 颗 处 理 器 的 Local timer 的 初始 化 如 下 : 


static void exynos4 mct tick init(struct clock event device *evt) 

{ 
// 取 出 CPU 号 
unsigned int cpu = smp_ processor id(); 
// 用 CPU 号 索引 对 应 数组 
mct tick[cpu] .evt = evt; 
/* 对 于 每 个 处 理 器 ， 其 Local timer 控制 寄存 器 的 基地 址 都 不 同 ， 偏 移 量 为 0x100: 
#define EXYNOS4 MCT L BASE (x) (_EXYNOS4 MCT L BASE+ (0x100*x)) 
而 且 其 中 断 类 型 为 PPI, 由 此 可 以 推断 ,Exynos4412 里 面 每 颗 处 理 器 都 有 一 个 Local timer 
的 具体 实现 ， 而 且 在 其 事件 发 生 时 仅 产生 PPI 中 断 。 这 是 较为 优美 的 Local timer 实现 ， 
比 4 个 SPI 中 断 好 多 了 */ 
mct tick[cpu] -base = EXYNOS4 MCT L BASE (cpu); 
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evt->name = mct tick[cpu]l .name; 

evt->cpumask = cpumask of (cpu); 

// set _ next event set mode 函数 设置 

evt->set next event = exynos4 tick set next event; 

evt->set mode = exynos4 tick set mode; 

// 该 Local timer 的 能 力 

evt->features = CLOCK EVT FEAT PERIODIC | CLOCK EVT FEAT ONESHOT; 
// 优 先 级 


evt->rating = 450; 


// 向 系统 中 注册 该 timer 
clockevents register device (evt); 
exynos4 mct write(TICK BASE CNT, mct tick[cpu] .base 事 
MCT_ LI_TCNTB_OFFSET) ; 
// mct_int type 的 值 是 MCT_INT_PPI， 不 用 考虑 SPI 中 断 了 
if (mct int type == MCT _ INT SPI) { 
if (cpu == 0) { 


} else { 
mct tickl event irq.dev id = &mct tick[cpul]; 
// 挂 载 中 断 
setup irq(IRQ MCT L1，&mct tickl event irq); 
// 中 断定 向 


irq set affinity(IRQ MCT L1, cpumask of(1)); 
} 
} else { 
// 这 里 使 能 该 PPI 中 断 ， 在 初始 化 刚 完成 时 GIC 的 PPI 中 断 是 disable 的 
gic_enable ppi(IRQ PPI MCT L); 


3.1.2 Tick 挂 载 


在 CA9 SMP 架构 下 ， 每 个 Core 使 用 自己 的 Local timer 作为 自己 的 tick 之 源 。 
在 arch/arm/kemelsmp.c 中 ， 内 核 为 每 颗 处 理 器 定义 了 自己 的 struct clock_event_device: 


Static DEFINE PER CPU (struct clock event device, percpu clockevent); 
在 每 个 Core 初始 化 时 ， 需 要 把 自己 的 Tick 源 打开 : 


void _cpuinit percpu timer setup(void) 
{ 
/* 取 得 自己 的 CPU 号 */ 
unsigned int cpu = smp processor id() 7 
/* 通 过 自己 的 CPU 号 索引 自己 的 struct clock event device*/ 
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struct clock event device *evt = &per cpul(percpu clockevent, cpu); 


evt->cpumask = cpumask of (cpu); 
evt->broadcast = smp timer broadcast; 
/*SOC 架构 相关 的 Local i 初始 化 ， 每 种 Soc 的 将 自己 的 Local timer 参数 填 入 
struct clock event device 结构 ,然后 调用 void clockevents register device!l(..), 
向 内 核 注 册 这 个 tick 设备 */ 
if(local timer setup(evt)) 

broadcast timer setupl(evt); 


} 
接 下 来 Core 检查 该 struct clock_event_device 是 否 符合 自己 的 Tick 设备 标准 。 


static int tick check new device(struct clock event device *newdev) 


{ 


cpu = smp_processor id(); 
/* 检 查 该 struct clock_event_device 指示 的 cpu mask 里 有 没有 自己 ， 要 是 没有 自己 ， 
说 明 不 符合 ， 直 接 退 出 */ 
if (!cpumask test cpul(cpu, newdev->cpumask)) 
goto out bc; 


/* 取 出 该 Core 当前 使 用 的 struct tick device*/ 
td = gper cpul(tick cpu device, cpu); 
curdev = td->evtdev; 


/* 检查 该 struct clock_event_device 是 否 是 当前 Core 的 Local 设备 */ 


if (!cpumask equal (newdev->cpumask, cpumask of (cpu) )) { 


/* 该 struct clock_event_device 不 是 当前 Core 的 Local 设备 */ 
/* 尝 试 将 该 设备 的 中 断定 向 分 发 给 当前 Core，Tick 需要 的 就 是 中 断 ， 如 果 不 是 Local 
timer， 但 是 如 果 其 中 断 能 定向 分 发 过 来 ， 也 可 以 */ 
if (!irq can set affinity(newdev->irq)) 
goto out bc; 


/* 当 前 的 struct clock_event device 是 Local 设备 ,就 没有 必要 再 换 成 非 Local 

设备 了 ， 即 使 精度 再 高 也 没 必 要 ， 这 种 Local 设备 在 架构 上 更 和 谐 */ 

if (curdev && cpumask equal (curdev->cpumask, cpumask of (cpu))) 
goto out bc; 


/* 在 新 老 设备 中 间 选 择 */ 
if (curdev) { 

/* 更 喜欢 CLOCK_EVT_FEAT_ONESHOT 的 设备 ,宁可 在 每 次 Tick 时 重新 设置 ， 也 不 要 
同期 性 的 ，ONESHOT 的 好 处 在 于 可 以 在 idle 时 做 tickless 。 一 般 的 Local timer 
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都 是 两 者 属性 兼 具 的 : CLOCK_EVT_FEAT PERIODIC | CLOCK EVT FEAT ONESHOT*/ 


if ((curdev->features & CLOCK EVT FEAT ONESHOT) && 
! (newdev->features & CLOCK EVT FEAT ONESHOT)) 
goto out bc; 
/* 别 的 因素 都 考虑 了 ， 以 优先 级 做 评判 标准 */ 
if (curdev->rating >= newdev->rating) 
goto out bc; 
} 


/* 新 的 struct clock event device 已 选 定 ， 下 面 将 挂 载 它 */ 


tick_setup_device (td，newdev，cpu，cpumask of (cpu) ) ; 


/*Tick 设备 的 建立 */ 


static void tick setup device(struct tick device *td, 


struct clock event device *newdev, int cpu, 


const struct cpumask *cpumask) 


ktime t next event; 
/* 记 录 当 前 Core 的 Tick 中 断 函 数 */ 


void (*handler) (struct clock event device *) = NULL; 


if (!'td->evtdev) { 


/* 这 时 Tick 还 没有 启 震 起 来 ， 还 不 知道 下 一 次 Tick 的 时 间 ， 所 以 做 周期 性 震荡 


*/ 
td->mode = TICKDEV_ MODE PERIODIC; 
} else { 


/* Tick 已 经 启 震 起 来 ， 知 道 下 一 次 Tick 的 时 间 ，struct tick_device 的 mode 保持 


原来 的 方式 ， 并 记录 Tick 的 中 断 handler */ 
handler = td->evtdev->event handler; 
next event = td->evtdev->next event; 


td->evtdev->event handler = clockevents handle noop; 


} 
/* 切 换 struct clock event device*/ 


td->evtdev = newdev; 


/* 如 果 不 是 Local 设备 ， 将 其 中 断 分 发 设置 为 定向 到 该 Core */ 


本 (!cpumask equal (newdev->cpumask, cpumask)) 


irq set affinity(newdev->irgq, cpumask); 


/* 下 一 步 ， 如 果 是 第 一 次 挂 载 td->mode == TICKDEV_MODE PERIODIC ， 


struct 
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clock event_device 的 成 员 变量 void (*event_hanqler) (..); 将 被 设置 为 void 
tick handle periodic(struct clock event device *dev), 这 是 该 Core 的 Tick 中 
断 函 数 。 

如 果 是 更 新 挂 载 ， 则 将 该 struct clock event device 的 工作 方式 设置 为 单 发 模式 : 
CLOCK EVT_ MODE _ ONESHOT， 并 重新 对 硬件 编程 设置 下 一 发 的 时 间 点 */ 


if (td->mode == TICKDEV MODE PERIODIC) 
tick setup periodic (newdev，0) 
else 
tick setup oneshot (newdev, handler, next event); 


} 
以 上 均 没 考虑 tick broadcast， 在 绝 大 多 数 手机 里 这 个 功能 是 disable。 


3.1.3 Tick 产生 


作为 系统 脉搏 ，Tick 发 生 时 ， 内 核 还 会 产生 一 些 动作 ， 如 编程 下 一 次 Tick 中 断 ， 更 新 


时 间 ， 人 触发 Timer 软 中 断 等 动作 ， 而 最 关键 的 是 将 Tick 送 入 调度 器 。 


/*Tick 处 理 的 框架 函数 , 一 方面 将 Tick 送 给 内 核 ,一 方面 编程 时 钟 寄 存 器 预定 下 一 次 Tick 的 到 
来 时 间 */ 
Void tick handle periodic(struct clock event device *dev) 
和 
int cpu = smp processor id(); 
ktime t next; 
/* 这 里 将 Tick 送 进 scheduler，Time 和 Timer 维护 的 工作 也 在 这 里 */ 


tick periodic(cpu); 


/* 下 面 要 确定 下 一 次 Tick 的 时 间 ， 如 果 该 设备 不 支持 CLOCK_EVT MODE _ ONESHOT， 那 么 
返回 即 可 ， 接 受 周期 中 断 */ 
if (dev->mode != CLOCK _EVT MODE ONESHOT) 
return; 
/* 对 下 一 次 Tick 中 断 产 生 的 时 间 进 行 硬件 编程 */ 
next = ktime add(dev->next event, tick period); 
for (77) { 
if (!clockevents program event (dev, next, ktime get())) 


return; 


} 

// 维 护 时 间 ， 并 将 Tick 继续 送 给 内 核 其 他 组 件 

static void tick periodicl(int cpu) 

: 

/* 每 个 Core 都 有 自己 Timer 队列 ， 但 是 Time 只 能 由 一 个 Core 来 维护 */ 


if (tick do timer cpu == cpu) { 
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/*Time 维护 ， 记 下 jiffies*/ 
do timer (1); 


} 
/*Timer 及 Tick 维护 */ 


update process times(user mode (get_irq regs())); 


| 
// 将 Tick 送 给 调度 器 ， 维 护 处 理 器 自己 的 Timer 队列 、 检 查 posix timer 
void update process _ times (int user tick) 
{ 
/*timer 维护 */ 
run local timers(); 
/*rcu 维护 */ 


rcu check callbacks (cpu, user tick); 


/* 把 tick 送 进 调度 器 */ 
scheduler tick(); 
/*posix timer 维护 */ 


run posix cpu timers(p); 


3.2 ”Fair 调度 类 


在 2.6 内 核 的 后 期 引入 了 调度 类 。 调 度 类 与 调度 队列 密 不 可 分 。 调 度 队列 是 实体 ， 
每 颗 处 理 器 一 个 ， 而 调度 类 为 策略 。 主 要 的 调度 类 有 RT、Fair、Idle 三 种 。 而 对 于 每 颗 处 
理 器 ， 所 有 这 些 调度 类 所 管辖 的 线程 队列 都 被 组 织 在 该 处 理 器 的 struct rq 队列 中 。 


3.2.1 Fair 调度 类 的 负载 均衡 


负载 均衡 操作 的 第 一 个 任务 是 统计 出 在 一 个 调度 域 最 繁忙 的 处 理 器 负载 。 这 分 为 两 
步 ， 第 一 步 在 调度 域内 找 出 最 繁忙 的 struct sched_group， 第 二 步 在 该 struct sched_group 中 
找 出 最 繁忙 的 处 理 器 。 对 于 CA9 架构 ， 尽 管 每 颗 处 理 器 都 有 自己 的 struct sched_domain 结 
构 ， 但 是 这 些 struct sched_domain 的 跨度 范围 是 包含 在 线 的 所 有 处 理 器 ， 所 以 ， 逻 辑 上 看 ， 
这 些 处 理 器 都 处 在 一 个 调度 域 中 。 再 者 , 对 于 CA9 架构 ,每 个 struct sched_group 只 包含 一 
个 处 理 器 ， 这 些 struct sched_group 又 被 组 织 成 一 个 环形 链表 (参见 调度 域 构建 部 分 )。 所 
以 在 CA9 架构 上 , 最 繁忙 的 处 理 器 寻找 可 以 看 作 遍 历 该 struct sched_group 环形 链表 , 寻找 
负载 最 重 的 处 理 器 。 

/* 该 函数 找 出 在 一 个 调度 域内 负载 最 高 的 struct sched group。 参数 struct sd lb stats 

*sds 用 于 记载 统计 结果 。struct sched domain *sd 为 当前 执行 负载 均衡 操作 处 理 器 对 应 
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struct sched domain 结构 

*/ 

static inline void update sd lb stats(struct sched domain *sd, int this cpu, 
enum cpu idle type idle, const struct cpumask *cpus, 


int *balance, struct sd lb stats *sds) 


struct sched domain *child = sd->child; 

/* 当 前 处 理 器 对 应 的 struct sched group ， 该 函数 的 主题 是 顺 着 这 个 struct 
sched _ group 遍历 该 调度 域 覆 盖 的 所 有 struct sched group*/ 

struct sched group *sg = sd->groups; 

// 用 于 存放 该 struct sched_group 负载 的 统计 结果 

struct sg lb stats sgs; 

int load idx, prefer sibling = 0; 


dof{ 


int local group; 
/*struct sched group 的 成 员 变 量 unsigned long cpumask[0]; 指 出 了 该 
struct sched_group 覆盖 的 处 理 器 ， 对 于 CA9 架构 ， 其 指出 了 包含 处 理 器 的 对 应 位 ， 
在 工 .mx69 架构 上 ， 其 取 值 为 1、2、4、8。 这 里 检测 要 统计 的 struct sched_group 
是 否 就 是 当前 处 理 器 对 应 的 struct sched_group*/ 
local group = cpumask test cpul(this cpu, sched group cpus (sg)); 
memset (gsgs, 0, sizeof (sgs)); 
// 提 取 该 struct sched_group 负载 信息 到 sgs 中 
update sg lb stats(sd, sg, this cpu, idle, load idx, 

local group, cpus, balance, &sgs); 
/* 当 前 处 理 器 对 应 struct sched_group 无 法 做 loadbalance 的 目标 ， 无 事 可 做 返 
回 */ 
if (local group && !(*balance)) 


return; 


if (local group) { 
// 统 计 目标 处 理 器 的 负载 
sds->this load = sgs.avg load; 

} else if (update sd pick busiest(sd, sds, sg, &sgs, this cpu)) { 
// 将 新 统计 处 理 出 来 的 sgs 与 原 有 sgs 中 最 忙碌 的 比较 ， 选 出 繁忙 处 理 器 
sds->max load = sgs.avg load; 
sds->busiest = sg; 


} 


// 链 表 里 的 下 一 个 struct sched group 
sg = sg->next; 
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} while (sg != sd->groups); 
} 


/* 统 计 一 个 struct sched group 内 的 所 有 处 理 器 负载 ， 对 于 CA9 架构 ， 每 个 struct 
sched_group 内 置 有 一 颗 处 理 器 */ 
static inline void update sg lb stats(struct sched domain *sd, 

struct sched group *group, int this cpu, 

enum cpu idle type idle, int load idx, 

int local group, const struct cpumask *cpus, 

int *balance, struct sg lb stats *sgs) 


/* 若 需要 统计 的 struct sched_group 包含 当前 处 理 器 ，balance_cpu 记录 下 该 struct 
sched_group 里 第 一 颗 处 理 器 ， 对 于 CA9 即 为 当前 处 理 器 */ 
if (local group) 

balance cpu = group first cpul(group); 


/* 针 对 struct sched_group 里 的 每 一 颗 处 理 器 操作 */ 
for each cpu and(i, sched group cpus(group), cpus) { 
struct rq *rq = cpu rq(i); 


if (local group) { 
/* 若是 当前 处 理 器 (目标 处 理 器 ) 的 struct sched_group， 即 把 负载 往 该 处 理 器 上 


拉 */ 
if (idle cpul(li) && !first idle cpu) { 
//Tick 发 生 在 Idle，cpnu 本 来 试图 分 担 别 的 处 理 器 的 负载 
first idle cpu = 1; 
balance cpu = i; 


} 
/* 取 出 该 处 理 器 的 负载 ， 对 于 Fair 调度 类 ， 在 线程 进 队 出 队 时 都 是 调整 处 理 器 的 


负载 ， 参 见 相关 章 节 */ 
load = target load(i, load idx); 


} else { 
/* 从 当前 处 理 器 角度 看 别 的 处 理 器 ， 取 出 其 负载 */ 


load = source load(i, load idx) 7 


} 
/* 累 计 struct sched_group 内 所 有 处 理 器 负载 ， 对 于 CA9 这 里 只 做 一 次 */ 


sgs->group_ load += load; 


/* 
在 schedule 中 若菜 个 运行 队列 可 运行 为 0， 面临 Idle 时 ， 出 现 以 下 情况 
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*/ 

if (idle != CPU NEWLY IDLE && local group) { 
/* 这 种 情况 要 做 balance 的 处 理 器 为 struct sched_group 里 第 一 颗 处 理 器 ， 否 则 
无 法 做 balance。 这 种 处 理 器 似乎 不 是 物理 处 理 器 ， 应 该 是 逻辑 处 理 器 ， 多 颗 逻 辑 处 理 
器 共享 相同 的 计算 单元 ，SMT 似乎 符合 这 种 情况 。 但 对 于 CA9 物理 处 理 器 就 是 逻辑 处 理 
器 ， 不 会 出 现 该 情况 */ 
if (balance cpu != this cpu) { 

*balance = 0; 


return; 


} 


事实 上 ， 实 际 情况 要 复杂 得 多 ， 可 能 根本 就 没有 符合 条 件 的 最 繁忙 处 理 器 ， 或 者 当前 
处 理 器 不 能 满足 作为 负载 转移 目标 条 件 。 这 里 还 隐藏 着 另外 一 个 影响 负载 的 因素 ， 即 Fair 
调度 类 和 Rt 调度 类 是 分 别 统计 负 载 的 ，Fair 的 负载 值 并 没有 直接 记录 RT 调度 类 的 线程 情 
况 。 但 是 如 果 某 个 调度 队列 上 RT 负载 较 重 ， 则 影响 到 其 Fair 调度 类 复制 值 的 消减 ， 这 样 
运行 RT 线程 的 处 理 器 上 ， 其 Fair 调度 类 的 负载 值 就 消逝 较 慢 ， 使 其 逐渐 成 为 Fair 调度 类 
的 busiest。 

负载 均衡 时 机 为 定时 、idle、newly_idle、nohz idle_ balance 四 种 情况 ， 前 三 种 情况 的 
特点 是 目标 处 理 器 都 是 当前 处 理 器 。 而 尽管 nohz idle_ balance 导致 的 loadbalance 框架 与 前 
三 者 相同 ， 但 其 目标 处 理 器 却 不 是 当前 处 理 器 。nohz_ idle balance 基本 机 理 是 : nohz idle 
在 idle 状态 去 除了 禁止 了 tick， 所 以 在 处 理 器 进入 nohz idle 之 间 ， 就 把 自己 标志 在 
idle_cpus_mask 位 图 中 。 在 别 的 active 处 理 器 发 生 tick 时 ， 将 该 处 理 器 作为 loadbalance 目 
标 处 理 器 。 

接 下 来 就 可 以 分 析 负 载 均衡 的 框架 函数 了 : 在 选 出 最 繁忙 的 处 理 器 之 后 ， 接 着 就 可 以 
做 负载 均衡 了 一 一 把 最 繁忙 处 理 器 上 的 线程 拉 到 目标 处 理 器 上 本 节 提 到 当前 处 理 器 都 是 
描述 前 三 种 调度 时 机 )。 


/* 
负载 均衡 框架 函数 ， 前 4 个 参数 都 是 描述 当前 处 理 器 的 ， 最 后 一 个 参数 描述 负载 均衡 完成 的 结果 
uf 


static int load balance (int this cpu, struct rq *this rqg, 
struct sched domain *sd, enum cpu idle type idle, 


int *balance) 


int ld moved, all pinned = 0, active balance = 0; 


redo: 


/* 找 出 最 繁忙 的 struct sched group*/ 


group = find busiest groupl(sd, this cpu, &imbalance, idle, 
cpus, balance); 


// 如 果 没有 满足 条 件 的 struct scheqd_group， 直 接 返 回 
if (*balance == 0) 


goto out balanced; 


/* 在 找到 的 struct sched_group 里 面 找到 繁忙 的 逻辑 处 理 器 ， 对 于 CA9 这 是 一 对 
系 */ 


busiest 


find busiest queue(sd, group, idle, imbalance, cpus); 


// 如 果 没 有 满足 条 件 的 逻辑 处 理 器 ， 直 接 返 回 

if (!busiest) { 
schedstat inc(sd, lb nobusyq[idle]); 
goto out balanced; 


// 1d_moved 记录 下 有 多 少 线程 发 生 了 处 理 器 间 移 动 

ld moved = 0; 

if (busiest->nr running > 1) { 
all pinned = 1; 
local irq save (flags); 
double rq lock(this rq, busiest); 
/* 把 最 繁忙 处 理 器 上 的 线程 移动 到 当前 处 理 器 上 ， 摘 取出 原 有 队列 再 入 队 的 过 程 */ 
ld moved = move tasks(this rq, this cpu, busiest, 

imbalance, sd, idle, &all pinned); 

double rq unlock(this rq, busiest); 
local irqg restore (flags) 7 


/* 


7 


-的 关 


若 目 标 处 理 器 不 是 当前 处 理 器 ， 置 位 TIF_NEED_RESCHED 使 得 目标 处 理 器 有 机 会 运行 


新 线程 ， 这 是 nohz_idle_balance 发 生 的 情况 

*/ 

if (ld moved && this cpu != smp_processor id()) 
resched cpul(this cpu); 


/* 最 繁忙 处 理 器 上 的 线程 都 是 处 理 器 绑 定 的 ， 不 能 被 转移 到 别 的 处 理 器 上 */ 
if (unlikely(all pinned)) { 
cpumask clear cpul(cpu of (busiest), cpus); 
if (!cpumask empty (cpus)) 
goto redo; 
goto out balanced; 
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3.2.2 Fair 调度 类 的 处 理 器 选择 


Fair 调度 类 的 目标 是 尽量 让 所 有 线程 得 到 公平 的 运行 时 机 ， 无 论 对 于 手机 还 是 嵌入 式 
系统 ， 绝 大 多 数 线程 都 是 属于 Fair 调度 队列 的 。 


/* 
该 函数 作为 struct sched class fair sched class 变量 的 int (*select task rq) 
(…) ;函数 ， 在 当 唤 醒 Fair 调度 类 的 线程 时 ， 为 线程 选择 合适 的 处 理 器 
*/ 
static int 
select task rq fair (struct task struct *p, int sd flag, int wake flags) 
{ 

struct sched domain *tmp, *affine sd = NULL, *sd = NULL; 

int cpu = smp processor id(); 

// 取 出 待 唤醒 线程 p 之 前 运行 的 处 理 器 

int prev cpu = task cpu(p); 

int new cpu = cpu; 

int want affine = 0; 

int want sd = 1; 

int sync = wake flags & WF_SYNC; 

// 在 CR9 的 架构 下 该 条 件 成 立 

if (sd flag & SD BALANCE WAKE) { 

// 检 查 线程 p 能 否 运行 在 当前 处 理 器 上 
if (cpumask test cpul(cpu, &p->cpus allowed)) 
want affine = 1; 
new_cpu = prev_cpu; 


rcu read lock() 
for each domain(cpu, tmp) { 


/* 

若 线 程 p 的 先前 处 理 器 与 当前 处 理 同属 于 一 个 调度 域 ， 且 线程 p 又 能 运行 在 当前 处 理 器 

上 。 则 affine sd 置 位 当前 处 理 器 对 应 struct sched_domain。 这 种 情况 是 CA9 处 

理 器 常见 路 径 

WF 

if (want affine && (tmp->flags & SD WAKE AFFINE) && 
cpumask test cpul(prev_cpu, sched _ domain _ span (tmp))) { 
affine sd = tmp; 


want affine = 0; 
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} 
if (affine sd) { 
/* 若 当前 cpu 处 于 idle 状态 则 选择 当前 cpu, 否则 若 线程 p 先前 cpu 处 于 idle 状态 
则 选择 其 先前 cpu， 否 则 在 该 调度 域 覆 盖 范 围 内 的 处 理 器 选择 一 个 处 于 idle 状态 的 运 
行 p。 若 找 不 到 idle 状态 处 理 器 则 直接 使 用 prev_cpu。 这 是 CA9 架构 最 常见 路 径 */ 


new cpu = select idle sibling(p, prev cpu); 


goto unlock; 


} 


/* 和 否则 在 调度 域 砂 盖 处 理 器 里 选择 一 个 最 空闲 的 处 理 器 来 运行 p*。 该 路 径 不 常见 ， 发 生 情况 
为 当前 处 理 器 不 在 线程 p 的 可 运行 处 理 器 列表 中 */ 
while (sd) { 

// 寻 找 最 空闲 struct sched_group 

group = find idlest group(sd, p, cpu, load idx) 


// 在 最 空闲 struct sched_group 中 寻找 最 空闲 处 理 器 


new_cpu = find idlest cpul(group, p, cpu); 


} 


return new_cpu; 


3.3 ”RT 调度 类 


3.3.1 ”RT 调度 类 的 基本 结构 


调度 策略 属于 SCHED_FIFO、SCHED _RR 的 task_struct， 属 于 RT 调度 类 ，RT 调度 
类 的 队列 组 织 结构 以 优先 级 为 核心 。 
(1) 处 在 运行 状态 的 每 个 相同 优先 级 的 task_struct 被 串 在 同一 队列 。 
(2) 内 核 构造 一 个 以 长 为 最 大 优先 级 的 链表 头 数组 ， 上 述 task struct 队列 以 优先 级 为 
索引 挂 在 对 应 的 链表 头 上 。 
(3) 通过 一 个 长 为 最 大 优先 级 的 位 图 表示 对 应 优先 级 是 否 有 处 在 运行 状态 的 
task_struct。 
定义 如 下 所 示 : 
struct rt prio array { 
// 表 示 对 应 优先 级 是 否 有 可 运行 task_struct 
DECLARE BITMAP (bitmap, MAX RT PRIO+1); /* include 1 bit for delimiter 


*/ 
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// 挂 载 task struct 队列 的 链表 头 
struct list head queue [MAX RT PRIO]; 
}; 


调度 类 提供 了 入 队 函 数 的 主要 策略 就 是 依据 其 优先 级 索引 对 应 链表 头 : 


static void enqueue rt entity(struct sched rt entity *rt se, bool head) 


{ 


// 根 据 优先 级 索引 链表 数组 


struct list head *queue = array->queue + rt se priol(rt se); 


// 将 其 挂 入 该 链表 头 
if (head) 
list add(grt se->run list, queue); 
else 
list add tail(&rt_se->run list, queue); 
/* 以 优先 级 为 索引 置 位 运行 时 位 图 ， 表 示 当 前 优先 级 链表 上 有 处 于 运行 状态 的 
task_ struct*/ 
_ set bit(rt se priol(rt se), array->bitmap); 
// 当 前 运行 队列 可 运行 task_struct 数 日 增 一 
inc rt tasks(rt se, rt rq); 


， 


/* 暴 器 给 调度 器 的 入 队 函 数 ，rq 为 将 要 加 入 的 调度 队列 ，p 即 为 需要 加 入 的 task_struct*/ 
static void enqueue task rt(struct rq *rq, struct task struct *p, int flags) 


{ 


// 挂 入 调度 队列 
enqueue rt entity(rt se, flags & ENQUEUE HEAD); 
/* 若 该 task_struct 不 是 调度 队列 rq 的 当前 线程 ， 且 该 task_struct 可 以 在 多 个 处 理 器 上 
运行 ， 则 将 其 该 队列 的 pushable_tasks 链表 ， 在 该 CPU 负载 严重 时 ， 该 Pushable_ tasks 
链表 上 的 task_struct 将 会 被 推送 到 别 的 处 理 器 上 */ 
if (!task current(rq, p) && p->rt.nr cpus allowed > 1) 
enqueue pushable task(rq, Pp); 


RT 调度 类 的 Tick 函数 充分 解释 了 SCHED FIFO、SCHED _RR 调度 策略 的 不 同 。 


static void task tick rt(struct rq *rq, struct task struct *p, int queued) 
{ 


/* 对 于 SCHED_FIFO 策略 的 task struct，Tick 无 效 , 这 种 类 型 的 如 果 不 是 自己 主动 放弃 
CPU， 不 被 更 高 优先 级 的 SCHED_FIFO 策略 task 抢占 ， 就 不 眠 不 休 一 直 跑 下 去 */ 
if (p->policy != SCHED RR) 


return; 


/* 对 于 SCHED_RR 调度 策略 的 task 仍 有 时 间 片 的 概念 ，Tick 到 来 其 time slice 仍然 被 


} 
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递减 */ 

if (--p->rt.time slice) 
return; 

// 递 碱 到 0， 恢 复 时间 片 的 默认 值 


p->rt.time slice = DEF TIMESLICE; 


/* 
把 当前 SCHED_RR 调度 策略 的 task 从 调度 队列 里 摘 掉 , 并 将 其 挂 到 队 尾 。 这 个 操作 体现 了 轮 
转 。 在 RT 里 只 有 一 个 task 时 ， 即 使 SCHED_RR 调度 策略 的 task 也 能 享受 到 FIFoO 的 待遇 
%{ 
if (p->rt.run list.prev != p->rt.run list.next) { 
requeue task rt(rgq, p, 0); 
set tsk need resched(p); 


/* 调 度 器 使 用 的 下 一 运行 task 选择 函数 ， 该 函数 蕴含 的 一 个 重要 机 制 是 ， 如 果 当 前 调度 类 选择 不 
出 来 合适 的 task， 则 调度 器 会 在 下 一 个 调度 类 里 寻找 ， 直 到 idle task*/ 


static struct task struct * pick next task rt(struct rq *rq) 


t 


struct sched rt entity *rt se; 
struct task struct *p; 
struct rt rq *rt rq; 


rt Ld = EEG->rt 


// 如 果 RT 调度 类 没有 处 在 运行 态 的 task， 则 说 明 没 有 合适 的 task 
if (unlikely(!rt rq->rt nr running)) 
return NULL; 
// 如 果 RT 调度 类 到 了 带宽 限制 阀 值 ， 则 说 明 没有 合适 的 task 
if (rt rq throttled(rt rq)) 
return NULL; 
// 选 取 下 一 最 高 优先 级 的 task， 参 考 进 队 操作 
dof{ 
rt se = pick next rt entity(rqg, rt rq); 


} while (rt rq); 

// 索 引 到 新 task 

p= rt task of(rt se); 

// 在 新 task 被 选取 时 与 RT 调度 队列 的 clock_task 时 钟 同步 


p->se.exec start = rq->clock task; 


return p; 
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常规 应 用 通常 是 不 会 跑 到 RT 调度 队列 中 的 ， 只 有 在 某 些 特定 实时 应 用 中 才能 大 量 使 
用 。 而 对 于 Android 系统 ， 早 期 的 版 本 RT 队列 基本 没有 用 到 ， 到 了 后 期 版 本 进行 了 优化 ， 
将 surfacefilnger 之 类 的 线程 进行 实时 性 改造 放 入 了 RT 队列 。 


3.3.2 Rt_Bandwidth 


为 了 限制 系统 中 RT 调度 类 过 度 占用 CPU， 内 核 提供 了 rt_bandwidth 机 制 ， 即 设置 一 
个 百分比 ， 当 RT 运行 队列 的 task 占据 CPU 的 时 间 超 过 了 这 个 阔 值 ， 则 调度 器 将 RT 调度 
类 视而不见 ， 将 剩 下 的 时 间 分 配给 其 他 调度 类 的 task。 

尽管 该 机 制 通过 全 局 变量 int sysctl_sched rt_runtime 来 控制 是 否 开启 。 但 是 在 大 多 数 
ARM 处 理 器 厂商 提供 的 BSP 里 都 是 默认 开启 的 ,所 以 对 于 某 些 依靠 最 高 优先 级 的 FIFO 实 
时 线程 来 说 要 注意 ， 这 种 情况 下 有 些 时 间 是 不 受 控制 的 。 若 默认 最 高 优先 级 且 处 于 运行 态 
的 FIFO 时 ， 线 程 能 totally 控制 系统 将 存在 潜在 bug。 

/* 

RT 调度 类 的 shchedule_tick 里 会 调用 该 函数 

*/ 
static void update curr rt(struct rq *rq) 


t 


struct task struct *curr = rq->curr; 
struct sched rt entity *rt se = &curr->rt; 
Struct Lt tu “rt rq = rt Tq oF se(rt ao)y 


u64 delta exec; 


if (curr->sched class != &rt sched class) 
return; 
/* 在 当前 task 被 调度 时 及 tick 发 生 时 ， 其 se.exec_start 与 RQ 的 clock task 同步 ， 参 
见 上 文 。 而 在 每 次 tick 时 ，RQ 的 clock task 与 系统 时 间 同 步 。void 
scheduler tick(void)-> static void update rq clock(struct rq *rq)-> static 
void update rq clock task(struct rq *rq，s64 delta) 。 所 以 这 里 求 出 来 的 差 值 之 和 
是 RT 调度 类 运行 的 时 间 长 度 */ 


delta exec = rq->clock task - curr->se.exec start; 


// 当 前 task 的 exec start 时 间 与 运行 队列 时 间 同 步 


Curr->se.exec start = rq->clock task; 
// 如 果 禁 用 了 rt_bandwidth 直接 返回 即 可 
if (!rt bandwidth enabled()) 

return; 


for each sched rt ent ity (rt se) 竺 


if (sched rt runtime(rt rq) != RUNTIME INF) { 
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// 防 抢占 防 中 断 
raw spin lock(grt rq->rt runtime lock); 
//rt_time 记录 了 RT 调度 类 运行 的 时 间 长 度 
rt rq->rt time += delta exec; 
/* 查 看 当前 RT 运行 时 间 长 度 是 否 超 过 了 rt_bandwidth 机 制 的 限制 ， 如 果 超 过 
了 限制 ， 则 进入 调度 器 */ 
if (sched rt runtime exceeded(rt rq)) 
/* 如 果 为 真 , 当前 task 置 为 TIF_NEED_RESCHED 运行 状态 , 即使 运行 态 的 FIFO 
task 也 得 交 出 处 理 器 */ 
resched task(curr); 
raw_ spin unlock(&rt rq->rt runtime lock); 


} 


// 检 查 否 超过 了 rt_bandwidth 机 制 的 限制 


static int sched rt runtime exceeded(struct rt rq *rt rq) 


{ 
//runtime 取 至 RQ 的 rt_runtime 成 员 变 量 ， 这 是 限制 的 时 间 点 


u64 runtime = sched rt runtime(rt rq); 


// 如 果实 际 运行 时 间 超 过 了 限制 的 运行 时 间 ， 则 rq 的 成 员 变 量 rt_throttled 为 真 
if (rt rq->rt time > runtime) { 
rt rq->rt throttled = 1; 


} 


return 0; 

} 

这 之 后 的 机 制 是 ， 当 前 CPU 进入 调度 器 ， 调 度 器 再 次 重 选 线程 ， 当 前 RT 调度 队列 被 
throttled， 所 以 RT task 选择 返回 NULL， 调 度 器 将 继续 尝试 Fair 直到 Idle。 这 其 中 列 藏 着 
一 个 问题 是 ， 如果 Fair 里 没有 task, 该 处 理 器 将 会 进入 到 Idle 中 , 尽管 这 时 RT 里 还 有 task 
没有 运行 完毕 ， 是 在 所 有 队列 中 都 没有 task 才 Idle， 还 是 不 管 如 何 都 从 RT 里 剥夺 一 定 的 
运行 时 间 ， 是 一 个 值得 讨论 的 问题 。 

为 了 控制 RT 调度 队列 的 throttled 与 active， 内 核 使 用 一 个 hrtimer 一 一 
sched rt_ period timer 来 处 理 这 个 机 制 。 

//Hrtimer 时 钟 的 处 理 函数 


static enum hrtimer restart sched rt period timer(struct hrtimer *timer) 


{ 


for (77) { 
// 取 出 当前 时 间 


now = hrtimer cb get _ time (timer); 
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/*forward 该 hrtimer ， rt b->rt period 的 一 个 周期 默认 为 一 秒 ， 


rt b->rt runtime 为 0.95 秒 。 这 些 值 在 void init rt bandwiqdth(...) 里 被 初始 化 */ 


overrun = hrtimer forward(timer, now, rt b->rt period); 
If (!overrun) 
break; 
/* 实 际 工作 函数 ， 在 一 个 周期 的 边沿 ， 检 查 是 否 重启 RT 调度 队列 ， 或 者 当前 RT 调度 队 
列 已 无 可 运行 task， 则 返回 idle*/ 
idle = do sched rt period timer (rt b, overrun); 
’ 
// 是 否 idle 来 决定 该 Hrtime 是 否 重新 fire 
return idle ? HRTIMER NORESTART : HRTIMER RESTART; 


static int do_sched rt period timer (struct rt bandwidth *rt b, int overrun) 


{ 


//idle 默认 为 1 


int i, idle = 1; 


// 取 出 在 线 处 理 器 位 图 

span = sched rt period mask(); 

// 只 针对 在 线 处 理 器 操作 

for each cpuli, span) { 
int enqueue = 0; 
struct rt rq *rt rq = sched rt period rt rql(rt b, i); 
struct rq *rq = rq of rt rql(rt rq); 


raw_spin lock(grq->lock); 
// 检 查 该 运行 队列 是 否 有 实际 运行 时 间 记 录 
if (rt rq->rt time) { 

u64 runtime; 


raw_spin lock(grt rq->rt runtime lock); 
// 有 实际 运行 时 间 记录 且 被 rt_throttled 
if (rt rq->rt throttled) 
balance runtime (rt rq); 
// 限 制 的 时 间 长 度 
runtime = rt rq->rt runtime; 
// 通 常 overrun 为 0， 这 里 rt_rq->rt time 被 清 零 
rt rq->rt time -= min (rt rq->rt time, overrun*runtime); 
//rt_rq->rt_time 被 清 零 ， 且 rt_rq->rt_throttled 为 真 
if (rt rq->rt throttled && rt rq->rt _ time < runtime) { 
// rt_throttled 状态 被 清 零 
rt rq->rt throttled = 0; 
enqueue = 1; 


/* 
发 生 在 RT 队列 throttled 时 ，Fair 里 却 没有 处 在 运行 状态 的 task 
sy 


if (rt rq->rt nr running && rq->curr == rq->idle) 
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rq->skip clock update = -1; 
// 发 生 在 RT 队列 运行 完毕 以 后 hrtimer 才 到 来 
if (rt rq->rt time || rt rq->rt nr running) 
idle = 0; 
raw_ spin unlock(g&rt rq->rt runtime lock); 
} else if (rt rq->rt nr running) { 
/* 该 RT 队列 对 应 的 CPU 刚 被 唤醒 ， 还 没 来 得 及 执行 第 一 个 RT task， 或 者 第 一 个 RT 
task 还 没 执行 到 第 一 个 TICK*/ 
idle = 0; 
if (!rt rq throttled(rt rq)) 
enqueue = 1; 
} 
/* enqueue 为 真 导 致 该 CPU 进 调度 器 ,( 对 于 最 后 一 种 情况 导致 多 进入 一 次 schedule) 
新 的 周期 开始 */ 
if (enqueue) 
sched rt rq enqueue (rt rq); 
raw_spin unlock (grq->lock); 
} 
/*idle 为 1 的 原因 在 于 ， 系统 压根 就 没有 RT task 或 者 RT 队列 的 task 在 一 个 周期 的 限 
制 之 内 就 运行 完毕 了 */ 
return idle; 


} 
3.3.3 ”负载 均衡 与 抢占 


负载 均衡 用 在 RT 调度 类 上 似乎 不 太 合适 ， 虽 然 存 在 推拉 动作 ， 但 这 并 不 是 为 了 平衡 
处 理 器 的 负载 ， 而 是 以 满足 实时 性 为 第 一 要 务 前 提 下 的 处 理 器 间 任 务 分 配 。 


1. 在 唤醒 时 刻 


(1) 在 处 理 器 选择 时 刻 : 若 被 唤醒 线程 优先 级 低 于 当前 处 理 器 当前 线程 优先 级 且 当 前 
处 理 器 当前 线程 不 能 在 别 的 处 理 器 上 运行 ， 则 为 被 唤醒 线程 选择 一 个 运行 低 优先 级 线程 的 
处 理 器 〈 仍 有 可 能 再 次 选择 到 当前 处 理 器 ， 参 见 唤醒 部 分 )。 

(2) 在 将 被 唤醒 线程 挂 入 目标 处 理 器 运行 队列 时 刻 : 

@ 若 被 唤醒 线程 优先 级 在 目标 RT 运行 队列 struct rt_rq 中 最 高 , 则 在 struct highest_prio 
的 结构 里 记录 下 被 唤醒 线程 。 

@ 若 被 唤醒 线程 可 以 在 多 个 处 理 器 上 运行 ， 则 将 其 挂 入 目标 RT 运行 队列 struct rt_rq 
的 struct plist_head pushable tasks: 链 表 。 值 得 一 提 的 是 ，task 挂 入 该 链表 的 顺序 是 以 其 优先 
级 为 顺序 ， 这 样 其 被 push 走 的 时 候 也 是 优先 级 由 高 而 低 依次 进行 。 而 每 次 push 线程 的 时 
候 是 在 其 余 处 理 器 上 线程 最 高 优先 级 低 于 被 push 的 线程 才 发 生 push 动作 ， 否 者 该 线程 还 
是 不 会 被 push 走 。 

(3) 在 优先 级 检查 时 刻 。 

Q@ 检查 目标 RT 运行 队列 上 的 当前 线程 是 否 可 以 抢占 ， 如 果 被 唤醒 线程 优先 级 较 高 ， 
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则 车 目标 RT 运行 队列 上 的 当前 线程 将 被 标志 TIF_ NEED RESCHED， 出 现 被 唤醒 线程 与 
目标 RT 运行 队列 上 的 当前 线程 优先 级 相同 又 出 现 如 下 情况 。 

。 若 被 唤醒 线程 能 在 多 个 处 理 器 上 运行 ， 则 什么 都 不 做 ， 因 为 被 唤醒 线程 现在 处 于 目 

标 RT 运行 队列 struct rt_rq 的 struct plist_ head pushable tasks: 链 表 中 , 它 有 可 能 被 推 


出 去 或 者 拉 出 去 。 
。 若 目 标 RT 运行 队列 的 当前 线程 和 被 唤醒 线程 都 只 能 在 目标 处 理 器 上 运行 ， 什 么 也 
做 不 了 。 


。 若 目 标 RT 运行 队列 的 当前 线程 可 在 其 他 处 理 器 上 运行 ， 则 被 唤醒 线程 抢占 当前 线 
程 ， 这 之 后 被 抢占 的 线程 将 有 机 会 被 推出 去 或 者 拉 出 去 到 别 的 处 理 器 。 
@ 在 唤醒 操作 的 最 后 一 动作 task_woken 时 刻 。 
若 被 唤醒 线程 不 能 抢占 当前 运行 队列 的 当前 线程 ， 且 被 唤醒 线程 可 以 在 多 个 处 理 器 上 
运行 ， 且 目标 RT 运行 队列 struct rt_rq 的 struct plist head pushable tasks: 链 表 不 为 空 ， 在 对 
于 该 链表 执行 push 操作 。 


2. 在 调度 器 的 pre_schedule 时 刻 


这 时 处 理 器 还 未 进行 新 的 线程 遵 选 ， 但 是 下 一 个 被 切换 上 的 线程 的 优先 级 低 于 当前 线 
程 的 优先 级 将 发 生 位 操作 。 这 里 的 逻辑 是 当前 线程 无 法 运行 , 且 不 是 被 高 优先 级 线程 抢占 ， 
那么 可 以 从 别 的 处 理 器 上 拉 过 来 优先 级 较 高 的 线程 。 


3. 在 调度 器 的 post_schedule 时 刻 
切换 完毕 ， 大 位 已 定 ， 没 选 上 的 线程 将 被 push 到 别 的 处 理 器 。 


3.3.4 基础 操作 


针对 多 处 理 的 优先 级 管理 ，Linux 内 核 使 用 了 如 下 结构 : 


struct cpupri { 
/* 该 数组 以 优先 级 为 索引 ， 每 一 数据 项 表示 对 应 优先 级 的 处 理 器 位 图 。 若 某 处 理 器 对 应 位 在 该 
位 图 为 真 ， 则 表示 该 处 理 器 运行 的 线程 的 最 高 优先 级 即 为 该 数据 项 的 索引 */ 
struct cpupri vec pri _to_cpu[CPUPRI_NR_PRIORITIES]; 
// 以 处 理 器 号 为 索引 ， 数 据 项 的 值 即 为 该 处 理 器 运行 的 线程 的 最 高 优先 级 
int cpu to pri[NR CPUS]; 
}; 


// 在 每 次 将 新 的 线程 加 入 RT 调度 队列 时 都 要 更 新 该 位 图 
void cpupri set(struct cpupri *cp, int cpu, int newpri) 
{ 

int *currpri = &cp->cpu to pri[cpul]; 

// 取 出 cpu 上 原 有 的 最 高 优先 级 

int oldpri = *currpri; 

int do mb = 0; 


//struct cpupri 优先 级 数值 不 同 于 线程 优先 级 数值 ， 值 越 大 优先 级 越 高 
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} 


newpri = convert prio (newpri); 


/* 若 新 挂 入 的 线程 优先 级 , 与 该 处 理 器 运行 队列 中 最 高 优先 级 的 线程 同 级 , 则 无 需 进 一 步 操作 ， 
返回 */ 
if (newpri == oldpri) 


return; 
if (likely(newpri != CPUPRI INVALID)) { 
// 以 优先 级 索引 处 理 器 位 图 
struct cpupri vec *vec = &cp->pri to cpulnewpril]; 
// 置 位 处 理 器 对 应 位 


cpumask_ set cpul(cpu, vec->mask); 


} 
if (likely(oldpri != CPUPRI INVALID)) { 
struct cpupri vec *vec = &cp->pri to cpul[loldpril]; 


// 清 除 掉 处 理 器 原 有 对 应 位 
cpumask_ clear cpul(cpu, vec->mask); 
} 
// 记 录 下 该 处 理 器 上 的 最 高 优先 级 


*currpri = newpri; 


在 唤醒 线程 和 push 操作 时 往往 需要 寻找 另外 一 颗 处 理 器 , 这 时 的 目标 是 其 上 运行 的 线 
程 优 先 级 最 低 ， 这 样 push 和 wake up 的 线程 才 有 机 会 立刻 运行 。 
// 其 中 P 为 被 唤醒 或 者 被 push 的 线程 


int cpupri find(struct cpupri *cp, struct task struct *p, 


{ 


struct cpumask *]lowest mask) 


int idx = 0; 
// 算 出 p 的 优先 级 在 struct cpupri 的 对 应 值 


int task pri = convert prio(p->prio); 


/* 从 优先 级 最 低 往 上 索引 ， 目 标 是 找 优先 级 最 低 的 ， 且 其 优先 级 不 能 高 于 p 的 优先 级 ， 否 则 
即使 把 push 或 者 wakeup 上 去 也 无 法 获得 处 理 器 */ 
for (idx = 0; idx < task pri; idx++) { 

struct cpupri vec *vec = &cp->pri to cpul[lidx]; 


/* 该 处 理 器 可 运行 处 理 位 于 与 上 优先 级 idx 对 应 位 图 ， 所 得 值 才 是 p 的 目标 处 理 器 */ 
if (lowest mask) { 
cpumask and(lowest mask, &p->cpus allowed, vec->mask); 
/* 计 算 结果 位 于 lowest_mask， 若 没有 合适 的 处 理 器 再 次 寻找 下 一 个 优先 级 对 应 
cpu 位 图 */ 
if (cpumask any (lowest mask) >= nr _ cpu ids) 
continue; 
} 
// 找 到 了 合适 的 处 理 器 


return 1; 
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/* 所 有 优先 级 低 于 p 的 位 图 都 找 了 ， 没 有 发 现 合乎 条 件 的 ， 返 回 0， 说 明 没 找到 */ 


return 0; 


3.4 调度 器 


3.4.1 调度 域 的 构建 


从 Linux 2.6 内 核 的 后 期 版 本 开始 , 内 核 使 用 了 调度 域 、 调 度 组 等 概念 来 组 织 处 理 器 之 
间 的 关系 。 由 于 笔者 目前 手头 上 能 找到 的 核心 数目 最 多 的 ARM 开发 板 仅 有 IMX6Q， 本 文 
仅 分 析 4 核 CA9 架构 下 的 调度 域 结构 。 

首先 针对 不 同 架构 的 层次 关系 内 核 使 用 如 下 结构 来 完成 调度 域 的 初始 化 : 

static struct sched domain topology level default topology[] = { 

// 超 线程 处 理 器 

#ifdef CONFIG SCHED SMT 

{ sd init SIBLING, cpu smt mask, }, 
#endif 


// 普 通 处 理 器 ， 对 于 CA9， 仅 有 该 项 
{ sd init CPU，cpu_cpu mask, }, 
//NUMA 机 器 
#ifdef CONFIG NUMA 
{ sd init NODE, cpu node mask, SDTL OVERLAP, }, 


#endif 
{ NULL, }, 
}; 


该 数组 反映 了 处 理 器 逻辑 的 拓扑 关系 ， 若 处 理 器 逻辑 单元 有 不 同 的 层次 ， 则 在 每 个 层 
次 上 都 有 对 应 拓扑 描述 结构 struct sched domain topology level 。 其 中 的 
sched_domain_mask fmask; 成 员 函 数 描述 了 在 该 层次 逻辑 处 理 器 对 应 分 组 关系 。 对 于 CA9 
处 理 器 ， 这 个 结构 数组 退化 为 仅 有 一 项 。 其 处 理 器 分 组 即 为 所 有 在 线 处 理 器 。 

以 struct sched_domain topology_level 为 基础 ， 调 度 域 实现 函数 如 下 : 


static int build sched domains(const struct cpumask *cpu map, 
struct sched domain attr *attr) 
{ CE 
/* 针对 每 一 颗 在 线 处 理 器 */ 
for each cpuli, cpu map) { 
struct sched domain topology level *tl; 
sd = NULL; 
/* 在 sched domain topology 的 每 个 层次 构建 调度 域 ， 对 于 CA9 架构 
sched_ domain topology 退化 为 仅 有 一 项 ， 所 以 整个 函数 退化 为 针对 每 个 处 理 
器 构建 其 调度 域 */ 
for (tl = sched domain topology; tl1->init; tl++) { 
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/* 对 每 个 处 理 器 构建 其 调度 域 ， 对 于 CA9 架构 ，sd 永远 为 0， 参见 下 文 */ 
sd = build sched domain(tl, &d, cpu map, attr, sd, i); 


} 
/* 对 于 CA9 架构 sd->child 为 0， 只 有 一 层 ， 但 是 对 于 其 他 架构 ， 这 就 构成 了 
调度 域 的 父子 关系 */ 
while (sd->child) 
sd = sd->child; 
// 记 录 下 处 理 器 的 调度 域 
*per cpu ptr(d.sd, i) = sd; 
} 


/* 为 每 个 调度 域 构建 struct sched group*/ 
for each cpuli, cpu map) { 
/* 对 于 CA9 架构 ， 其 调度 域 仅 为 一 层 ， 这 里 就 退化 为 针对 每 颗 处 理 器 的 struct 
sched_ domain 构建 其 struct sched group*/ 
for (sd = *per cpu ptr(d.sd，i); sd; sd = sd->parent) { 
// 计 算 一 下 该 调度 域 覆 盖 多 少 处 理 器 
sd->span weight = cpumask _ weight (sched _ domain span(sd) ) 
if (sd->flags & SD OVERLAP) { 
/* 对 于 CA9 架构 ， 其 调度 域 属性 里 没有 SD_OVERLAP， 不 可 能 走 
到 这 里 */ 
if (build overlap sched groups(sd, i)) 
goto error; 
} else { 
// 构 建 struct sched_group， 参 见 下 文 
if (build sched groups (sd, i)) 
goto error; 


} 


/* 执 行 到 这 里 ， 对 于 工 .MX6Q 处 理 器 ， 在 其 4 颗 处 理 器 均 online 情况 下 ， 调 度 域 、 调 度 组 的 构建 
如 图 3-1 所 示 */ 


rcu read lock(); 
// 每 颗 处 理 器 的 运行 对 于 struct rq 与 其 调度 域 struct sched_domain 绑 定 起 来 
for each cpuli, cpu map) { 
sd = *per cpu ptr(d.sd, i); 
cpu attach domain(sd, d.rd, i); 
} 


rcu read unlock(); 


return ret; 


} 
最 终 得 到 如 图 3-1 所 示 的 调度 域 结构 。 
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sd init CPU 


GPa _cpu_mask 


structsd data 。 data 


一 一 


Union {void *private;struct rcu_head rcu:}; 


struct sched_group *groups; 


struct sched_domain *child;//0 


unsigned int span_weight://4 


unsigned long span[0]://OxF 


struct sched_domain 
‘anion {void *private:stmuctrcu_head reu;}; 


Struct sched_group *groups; 
struct sched_domain *child/0 
struct sched_group *next; 
Struct sched_group_power “sgp; 
unsigned int span_weight//4 ‘unsigned long cpumask[0];//4 
unsigned long span[0],/0xF 


和 re hed poop roe 
union {void *private;struct rcu_bead rcu;}; Struct sched_group_power *sgp: 
Struct sched_group *groups; ‘unsigned long cpumask[0]://8 


Sstruct sched_domain *child;//0 


unsigned int span_weight//4 


unsigned long span[0];/0xF 


union {void *private;struct reu_head reu;}; 
Struct sched_group *groups; 一 
struct sched_domain *child;//0 


unsigned int span_weight,//4 
unsigned long span[0]:/0xF 


图 3-1 调度 域 和 调度 组 的 构成 


/* 单 个 调度 域 的 构建 。 对 于 CA9，t1 即 为 { sd init CPU，cpu cpu mask，},，child 为 0*/ 
struct sched domain *build sched domain(struct sched domain topology_ 
level *tl], 

struct s data *d, const struct cpumask *cpu map, 


struct sched domain attr *attr, struct sched domain *child, 


int cpu) 
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/*struct sched domain 结构 本 身 的 内 存 已 经 分 配 ， 这 里 通过 percpu 的 指针 找到 对 应 
cpu 的 struct sched domain, 并 将 其 赋值 为 SD CPU INIT*/ 
struct sched domain *sd = tl->init(tl, cpu); 
if (!sd) 
return child; 
/* 给 调度 域 的 unsigned long span[0] ;赋值 ， 该 值 描述 了 调度 域 覆 盖 的 处 理 器 范围 ， 对 
于 CA9， 其 值 为 cpu_online mask*/ 
cpumask and(sched domain span(sd), cpu map, tl->mask (cpu)); 
/*child 参数 反映 出 处 理 器 的 逻辑 关系 ， 从 最 底层 的 smt 开始 ， 层 次 逐渐 增长 ， 且 当前 调度 
域 是 前 一 级 调度 与 的 父亲 。 对 于 CA9 架构 不 用 考虑 这 个 */ 
3 (chilay { 
sd->level = child->level + 1; 
sched domain level max = max(sched domain level max, sd->level); 
child->parent = sd; 
} 
//CA9 的 调度 域 child 和 parent 都 为 0 
sd->child = child; 
set domain attribute(sd, attr); 


return sd; 


/* 

* build sched groups will build a circular linked list of the groups 

* Covered by the given span, and will set each group's ->cpumask correctly, 
* and ->cpu power to 0. 

代码 注释 很 好 地 解释 了 该 函数 的 作用 ， 值 得 一 提 的 是 针对 调度 域 履 盖 范围 内 的 所 有 struct 
sched_group 构建 ， 仅 在 第 一 颗 处 理 器 struct sched_group 构建 时 就 全 部 完成 

*/ 

static int 

build sched groups(struct sched domain *sd, int cpu) 


4 


// 若 该 处 理 器 不 是 其 调度 域 覆 盖 范 围 的 第 一 颗 处 理 器 ， 返 回 
if (cpu != cpumask first(sched _ domain span(sd))) 


return 0; 


// 针 对 调度 域 覆 盖 范 围 的 每 一 颗 处 理 器 
for each cpul(li, span) { 
struct sched group *sg; 
/* 其 struct sched_group 内 存 早已 分 配 ， 这 里 在 struct sched group *sg 里 
记录 其 地 址 */ 
int group = get groupl(i, sdd, &sg); 
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/* 清 楚 struct sched group 的 unsigned long cpumask[0];*/ 
cpumask clear (sched group cpus(sg)); 
sg->sgp->power = 0; 
/* 对 于 CA9， 该 循环 的 逻辑 关系 得 到 简化 ， 即 为 针对 i 对 应 的 struct sched group， 
将 其 unsigned long cpumask[0]; 对 应 的 第 位 置 1*/ 
for each cpu(j, span) { 
if (get group(j, sdd, NULL) != group) 


continue; 


cpumask set cpul(j, covered); 
cpumask set cpu(j, sched group cpus(sg)); 


} 
/* 将 该 调度 域 覆盖 范围 内 的 所 有 struct sched_group 串 起 来 */ 
if (!first) 
first = sg; 
if (last) 
last->next = sg; 
last = sg; 
} 


last->next = first; 


return 0; 


} 
3.4.2 ”调度 器 


在 基于 Linux 的 系统 中 ， 无 论 内 核 态 还 是 用 户 态 ， 任 何 时 刻 、 任 何 一 行 代码 都 必定 属 
于 一 个 线程 。 线 程 运行 时 的 边界 就 是 调度 器 。 调 度 工作 由 调度 算法 和 切换 组 成 ， 两 者 之 间 
泾 滑 分 明 。 调 度 算法 是 指 在 调度 队列 选择 线程 的 策略 ， 调 度 算法 没有 好 坏 ， 只 有 适合 与 不 
适合 之 分 。 

切换 的 作用 是 保存 被 调度 下 去 线程 的 Context 上 且 恢复 下 一 个 占用 处 理 器 的 线程 Context 
的 工作 。ARM 架构 处 理 器 大 量 使 用 到 了 协 处 理 器 , 而 协 处 理 器 有 着 大 量 的 寄存 器 Context， 
这 些 Context 的 保存 恢复 将 很 大 程度 影响 到 切换 时 间 。 但 是 系统 中 使 用 到 协 处 理 器 的 线程 
并 不 多 ， 如 Android 系统 中 仅仅 自 编 解码 多 媒体 线程 才 会 用 到 Neon， 而 且 它 们 同时 出 现在 
同一 个 处 理 器 核心 运行 队列 的 概率 又 更 小 了 。 所 以 这 就 为 切换 优化 提供 了 前 提 ，ARM 切 
换 器 的 做 法 ， 若 下 一 线程 不 使 用 协 处 理 器 则 协 处 理 器 的 Context 可 不 必 切 换 。 

切换 时 系统 中 值得 关注 的 另外 一 个 问题 是 Cache, 若 Cache 是 依据 于 虚拟 地 址 组 织 的 ， 
那么 若 发 生 跨 进程 线程 的 切换 时 势必 要 更 新 Cache， 否则 数据 就 混乱 了 。ARM 早期 架构 如 
ARM9 的 Cache 组 织 无 疑 是 VIVT 的 ， 这 样 对 于 Linux 这 种 有 着 独立 虚拟 地 址 空间 的 进程 
模型 每 次 进程 切换 Cache 都 要 更 新 一 遍 。 这 里 不 得 不 承认 早期 WINCE5S 之 前 的 多 个 进程 共 
享 4G 虚拟 地 址 空间 的 方式 在 这 个 方面 更 胜 一 筹 .在 CA8 之 后 的 ARM 实现 中 L2 和 Ll Data 
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Cache 通常 实现 为 PIPT, 只 有 Ll Instruction Cache 才 采 用 VIPT, 这 样 在 进程 切换 时 虚拟 地 
址 空间 的 问题 仅 影 响 到 工 1 Instruction Cache。 


/* 
调度 器 函数 ， 线 程 边界 ， 该 函数 有 两 个 潜在 的 参数 ， 当 前 线程 ， 当 前 处 理 器 调度 队列 
“六 


static void _sched _schedule(void) 
{ 
need resched: 
// 禁 止 抢 占 
preempt disable(); 
// 获 取 当 前 处 理 器 号 
cpu = smp_processor id(); 
// 根 据 处 理 器 号 索引 该 处 理 器 对 应 的 运行 队列 
rq = cpu rq(cpu): 
//rcu 相关 ， 参 见 rcu 部 分 
rcu note context switch(cpu); 
// 当 前 cpu 运行 队列 成 员 变量 struct task_struct *curr， 指 向 当前 线程 


prev = rq->curr; 


// 关 中 断 


raw_spin lock irq(&rq->lock); 


switch count = gprev->nivcsw; 
/* 处 理 当 前 线程 在 非 被 抢占 且 退 出 运行 态 时 的 情况 */ 
if (prev->state && !(preempt count() & PREEMPT ACTIVE)) { 
// 若 当前 线程 
if (unlikely(signal pending state(prev->state, prev))) { 
prev->state = TASK RUNNING; 


} else { 
/* 普 通 情况 ， 当 前 线程 在 自身 遇 到 无 法 继续 运行 的 情况 ， 而 导致 线程 切换 ， 将 当前 线 
程 从 运行 队列 中 取出 */ 


deactivate task(rq, prev, DEQUEUE SLEEP) ; 
/*struct task_struct 结构 的 成 员 变 量 int on_rq; 指 出 当前 线程 已 不 在 运行 
队列 */ 


prev->on rq = 0; 


if (prev->flags & PF WQ WORKER) { 
struct task struct *to wakeup; 


to wakeup = wq_worker sleeping (prev, cpu); 
if (to wakeup) 
try to wake up local (to wakeup); 
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switch count = &prev->nvcsw; 


pre_schedule (rq, prev); 
/* 若 当前 处 理 器 的 运行 队列 上 没有 处 于 运行 态 的 线程 , 需要 从 别 的 处 理 器 上 拉 些 线程 到 自己 的 
运行 队列 */ 
if (unlikely(!rq->nr running)) 
idle balance(cpu, rq); 
/* 处 于 运行 态 的 线程 , 并 没有 从 运行 队列 中 被 拿 掉 , 处 理 非 运行 态 线程 也 不 能 再 放 入 运行 队列 ， 
对 不 同 的 调度 类 有 不 同 的 处 理 ，RT 调度 类 做 的 工作 是 整理 运行 队列 及 当前 线程 的 运行 时 间 
且 对 运行 态 的 task 重新 决定 其 运行 的 处 理 器 */ 
put prev task(rgq, prev); 
/* 选 取 下 一 个 合适 的 线程 ， 对 于 每 颖 处 理 器 ， 其 选择 新 线程 的 顺序 依次 是 RT 调度 类 、Fair 
调度 类 和 Idle 调度 类 。 若 选择 了 Idle 调度 类 这 说 明 该 处 理 器 要 进入 Idle*/ 
next = pick next task(rq); 
// 清 楚 当前 线程 的 需要 调度 标志 
clear tsk need resched (Prev) 
rq->skip clock update = 0; 
/* 再 次 选取 的 线程 ， 可 能 就 是 当前 线程 ， 这 种 情况 直接 调 出 调度 函数 即 可 ， 否 则 需要 进行 切换 
操作 */ 
if (likely(prev != next)) { 
rq->nr_ switches++; 
// 当 前 运行 队列 更 新 自己 的 当前 线程 指针 
rq->curr = next; 
++*switch count; 
/7 线程 切换 ， 从 这 里 开始 当期 线程 发 生 改 变 
Context_switch (rq，PIeVv，mnext); /* unlocks the rq */ 
/* 新 老 线程 都 从 这 里 出 来 ， 只 不 过 老 线程 跑 到 这 里 时 是 其 被 下 一 次 调度 选中 ， 甚 至 是 在 
另外 一 颗 处 理 器 上 ， 新 线程 是 完成 了 虚拟 内 存 切换 〈 新 进程 )， 将 上 次 保存 在 寄存 器 信息 
恢复 到 处 理 器 后 即刻 运行 到 这 里 */ 
cpu = smp_processor id(); 
rq = cpu rql(cpu); 
} else 
raw_spin unlock irq(&rq->lock); 


post_schedule (rq); 


// 清 除 当前 线程 的 禁止 抢占 标识 

preempt enable no resched(); 

/* 在 新 线程 完成 切换 到 运行 到 这 里 的 时 候 发 生 了 中 断 ， 且 唤醒 了 更 高 优先 级 的 线程 ,导致 当 前 
线程 被 抢占 (新 线程 在 void finish task switch(..) 时 会 打开 中 断 ) */ 

if (need resched()) 


goto need resched; 
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3.5 唤 醒 


3.5.1 唤醒 与 抢占 


唤醒 意味 着 将 线程 状态 切换 成 可 运行 ， 本 节 首先 分 析 内 核 的 唤醒 操作 ， 在 SMP 架构 
处 理 器 环境 下 ， 除 了 涉及 基本 运行 队列 的 进 队 操作 ， 还 需要 通过 相应 调度 类 进行 处 理 器 的 
选择 。 

1. 唤醒 

/* 该 函数 作为 等 待 队 列 唤醒 的 缺 省 函数 ， 是 唤醒 指定 线程 最 常用 函数 */ 


static int 


try to wake upl(struct task struct *p, unsigned int state, int wake flags) 


' 


// 锁 raw_spinlock t pi_lock; 关 中 断 
raw_spin lock irqsave(g&p->pi lock, flags); 


cpu = task_ cpu(p); 
/* 这 里 的 发 生 情 况 为 。， p 在 另外 一 颗 处 理 器 上 已 置 为 不 可 运行 状态 ， 接 下 来 进入 调度 器 ， 但 
是 在 另外 一 颗 处 理 器 上 调度 器 还 没 走 到 raw_spin_lock irq(&rq->lock);， 这 时 在 当前 
处 理 器 就 唤醒 了 该 p， 这 时 p->on_rq 仍 有 效 ， 当 前 处 理 器 与 另 一 颗 处 理 器 竞争 对 方 处 理 器 
的 raw_spinlock t lock; (函数 static int ttwu remote(..) 通 过 rq = 
_ task_rq_lock (p) ;来 竞争 对 方 raw_spinlock t lock; )， 若 当前 处 理 器 获胜 ， 该 P 
通过 快捷 操作 被 重新 置 位 运行 状态 ， 若 对 方 处 理 器 获胜 该 p，wake up 操作 进入 下 面 常规 唤 
醒 操 作 */ 
if (p->on rq && ttwu remote(p, wake flags)) 

goto stat; 


#ifdef CONFIG SMP 
/* ”调度 器 在 完成 切换 时 会 将 切换 上 的 处 理 器 struct task_struct 中 的 int on_cpu; 
置 1， 而 将 被 切换 掉 的 处 理 器 struct task_struct 中 的 int on_cpu; 置 零 。 若 某 架 构 处 
理 器 切换 时 希望 能 同时 打开 中 断 ， 则 宏 RARCH WANT _INTERRUPTS_ON_CTXSW 和 
ARCH_WANT_UNLOCKED_CTXSW 被 定义 。 这 意味 着 在 切换 操作 的 进行 中 ， 该 处 理 器 的 中 断 
是 打开 的 且 其 切换 函数 不 持 有 其 运行 的 队列 struct rq 的 raw_spinlock t lock; 锁 */ 
while (p->on cpu) { 
#ifdef ARCH WANT INTERRUPTS ON CTXSW 
/* 
这 里 发 生 以 下 情况 : 
(1) 当前 处 理 器 上 唤醒 该 struct task struct *p， 但 该 p 在 对 方 处 理 器 上 正 处 在 已 经 
从 rq 的 运行 队列 被 取 掉 ， 其 on_rq 失效 ， 且 在 被 切换 掉 的 过 程 中 ， 其 on_cpu 依然 有 效 。 这 时 ， 
当前 处 理 器 只 需 在 获得 对 方 处 理 器 rq 的 raw_spinlock t lock; 后 将 该 p 重新 挂 入 其 运行 队列 
即 可 。 
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(2) 当前 处 理 器 上 唤醒 该 struct task struct *p， 同 时 对 方 处 理 器 其 在 p 切换 过 程 中 
发 生 的 了 中 断 , 且 该 中 断 做 唤醒 p 的 操作 。 这 时 当前 处 理 器 持 有 p 的 raw spinlock tpi lock;， 
而 对 方 处 理 器 持 有 却 在 该 p 的 raw_spinlock t pi lock; 上 等 待 ， 但 对 方 处 理 器 隐 性 持 有 
on_cpu 为 真 的 条 件 。 所 以 接 下 来 当前 处 理 器 在 该 p 重新 挂 入 其 运行 队列 后 即刻 释放 掉 该 p 的 
raw Spinlock t pi lock; 
*/ 


if (ttwu activate remote(p, wake flags)) 


goto stat; 
#else 
cpu relax(); 

#endif 

} 

/* 

接 下 来 是 常规 的 唤醒 操作 

*/ 

smp_rmb(); 


p->sched contributes to load = !!task contributes to load(p); 
p->state = TASK_ WAKING; 
/* 对 于 fair 调度 类 ， 为 p 选择 一 颗 负载 最 低 的 处 理 器 ， 对 于 RT 调度 类 选择 处 理 器 的 原则 是 
以 保证 该 p 能 及 时 运行 为 前 提 ， 分 为 以 下 情况 : 
(1) 若 p 上 次 运行 的 处 理 器 上 当前 运行 的 不 是 RT 线程 ， 则 继续 选择 p 上 次 运行 的 处 理 器 ， 
在 后 面 的 wake up 操作 中 p 将 抢占 该 处 理 器 。 
(2) 若 p 上 次 运行 的 处 理 器 上 当前 运行 的 是 RT 线程 ， 且 该 RT 线程 优先 级 高 于 p 或 者 该 RT 
线程 绑 定 了 该 处 理 器 ， 则 需要 为 p 选择 另外 一 颗 处 理 器 其 运行 
*/ 
if (p->sched class->task waking) 
p->sched class->task waking (p); 


// 为 该 p 选择 一 颗 合适 的 处 理 器 
cpu = select task rq(p, SD BALANCE WAKE, wake flags); 
if (task cpu(lp) != cpu) { 
wake flags |= WF _ MIGRATED; 
// 为 pp 设置 新 的 处 理 器 
set task cpul(p, cpu); 
站 
#endif /* CONFIG SMP */ 
/* 若 该 p 选 定 的 处 理 器 为 当前 处 理 器 ,把 p 挂 到 对 应 处 理 器 调度 队列 中 , 或 者 将 p 挂 到 对 方 处 理 器 
的 struct task struct *wake 1ist; 队 列 中 ， 并 向 对 方 处 理 器 发 送 处 理 器 间 中 断 。 对 方 处 理 
器 在 收 到 中 断后 处 理 该 struct task struct *wake 1ist; 队 列 。 参见 下 文 */ 
ttwu_queue (P， cpu); 


out: 
// 解 raw_spinlock t pi lock; 开 中 断 


raw_spin unlock irqrestore(gp->pi lock, flags); 
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return success; 


} 
2. 抢占 


唤醒 在 逻辑 上 属于 调度 的 一 部 分 ， 是 调度 时 机 产生 的 源泉 。 在 新 的 线程 被 唤醒 时 ， 内 
核 将 检查 当前 线程 是 否 能 够 抢占 其 对 应 运行 队列 上 的 当前 线程 。 在 线程 被 唤醒 后 内 核 使 用 
static void check_preempt_curr(...) 来 检查 抢占 条 件 。 


static void check preempt curr(struct rq *rq, struct task struct *p, int flags) 
{ 


const struct sched class *class; 


if (p->sched class == rq->curr->sched class) { 
/* 被 唤醒 p 所 属 调度 类 与 指定 rq 当前 线程 属于 同一 调度 类 ， 则 将 抢占 条 件 的 检查 交 与 具体 调 
度 类 */ 


rq->curr->sched class->check preempt curr(rq, p, flags); 
} else { 
/* 对 与 被 唤醒 p 所 属 调度 类 与 指定 rq 当前 线程 不 属于 同一 调度 类 的 情况 ， 其 原则 是 RT 调度 
类 抢占 Fair 调度 类 ， 从 最 高 优先 级 的 RT 调度 类 往 下 检查 */ 
for each class(class) { 


// 指 定 rq 当前 线程 所 属 调度 类 优先 级 更 高 ， 没 有 必要 抢占 


if (class == rq->curr->sched _ class) 
break; 

// 线 程 p 所 属 调度 类 优先 级 更 高 ， 抢 占 

if (class == p->sched class) { 


resched task(rq->curr); 
break; 


} 
3.5.2” 跨 处 理 器 分 发 线程 


当 一 颗 处 理 器 将 线程 均衡 给 别 的 处 理 器 时 或 唤醒 了 一 个 应 该 在 其 他 处 理 上 运行 的 线 
程 时 ， 这 些 线程 并 不 是 立即 处 于 目标 处 理 器 的 运行 队列 ， 而 是 位 于 其 wake list， 这 时 需要 
该 处 理 器 发 起 处 理 器 间 中 断 ， 以 通知 目标 处 理 器 接受 这 些 线程 。 


// 首 先 ， 发 送 方 处 理 器 发 起 RESCHEDULE 
void smp_send reschedule (int cpu) 
{ // 处 理 器 间 中 断 ，cpu 为 对 方 处 理 器 号 
smp_cross call(cpumask of(cpu), IPI RESCHEDULE); 
} 
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/* 接 着 ， 在 目标 侧 的 处 理 器 上 将 接收 到 IPI 中 断 ITPI_RESCHEDULE， 从 而 激活 其 线程 队列 */ 
asmlinkage void exception irq entry do IPI(int ipinr, struct pt regs 
*regs) 


{ 
switch (ipinr) { 


// 处 理 器 线程 队列 激活 分 支 ， 在 这 里 响应 对 方 处 理 器 
case IPI RESCHEDULE: 

scheduler ipi(); 

break; 


} 

接着 目标 侧 处 理 中 依次 检查 自己 的 wake_list, 将 其 中 线程 一 一 激活 , 该 wake_list 往往 
是 对 方 处 理 器 因为 自身 繁忙 或 者 由 于 优先 级 原因 挂 载 过 来 的 线程 队列 。 

//1ist 即 为 该 处 理 运行 队列 的 wake_1ist 

static void sched ttwu do pending(struct task struct *1ist) 


人 


// 使 用 ttwu_do_activate 函数 依次 执行 激活 操作 
while (list) { 

struct task struct *p = list; 

list = list->wake entry; 

ttwu do activate(rqg, p, 0); 


3.5.3 抢占 


抢占 分 为 用 户 态 抢占 和 内 核 态 抢 占 。 前 者 是 Linux 基本 特性 ， 后 者 在 打开 内 核 配 置 开 
关 时 被 激活 。 抢 占 是 实时 性 的 基础 ， 但 是 实时 性 的 好 坏 决定 于 内 核 访问 控制 的 粒度 。 通 过 
将 内 核 访问 控制 更 细 力 度 的 修改 ， 可 以 获得 更 好 的 实时 性 。 本 节 仅 分 析 单 核 处 理 器 下 抢占 
情况 。 

1. 避免 抢占 的 方法 


当 内 核 有 段 代码 段 需要 受到 保护 而 不 能 受 高 优先 级 task 打扰 时 ,为 了 保护 这 段 代码 段 ， 
内 核 在 其 前 后 加 入 : 
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preempt disable() 7 
受 保护 的 代码 段 : 
preempt enable(); 


其 中 preempt _ disable0 往 该 task 的 struct thread info 的 preempt count 里 0 一 7 位 加 1， 
表示 自己 已 经 进入 非 抢占 代码 段 。 


2. 禁止 抢占 状态 时 发 生 了 中 断 ， 唤 醒 高 优先 级 线程 ， 试 图 抢占 


这 时 一 个 硬件 中 断 进 入 ， 导 致 另 外 一 个 task 被 唤醒 ， 而 这 个 task 优先 级 高 于 当前 优先 
级 ， 并 且 当前 task 的 调度 类 属于 RT， 这 时 当前 task 的 flags 的 重新 调度 位 被 置 位 。 接 着 该 
中 断 返回 时 检查 当前 task 的 preempt_count 非 零 ， 所 以 不 能 被 抢占 ， 硬 件 中 断 只 好 乖 午 的 
退出 ， 同 时 恢复 当前 task 的 受 保护 代码 段 的 执行 。 

然后 当当 前 task 的 受 保护 代码 段 执行 完毕 ， 它 调用 了 preempt_enable0， 将 自己 在 
preempt_count 里 的 0 一 7 位 所 加 的 1 清除 。 但 是 这 时 内 核 又 检查 自己 当前 task 的 flags 的 
TIF NEED RESCHED 是 否 被 置 位 。 很 明显 刚才 进入 硬件 中 断 ， 将 该 位 置 位 ， 于 是 内 核 开 
始 抢占 ， 当 前 task 被 设置 为 PREEMPT _ ACTIVE 状态 ， 内 核 进入 schedule 选择 新 的 task。 

接 下 来 分 析 上 述 场景 对 应 的 代码 : 

中 断 处 理 函 数 使 用 static int try_to_wake_up(.…) 唤 醒 一 个 task 时, 这 时 调度 队列 的 状态 
发 生 了 变化 ， 有 必要 检查 一 下 是 否 将 当前 task 抢占 掉 。 


static int try to wake up(struct task struct *p, unsigned int state, int 


sync) 


t 


struct rq *rq; 


//rq 是 当前 处 理 器 运行 队列 
rq = task rq lock(p, &flags); 


//p 是 要 被 抢占 的 task 


check preempt currl(rq, p, sync); 


} 


static inline void check preempt curr(struct rq *rq, struct task struct *p, 

int sync) 

{ 

// 找 到 当前 运行 队列 的 当前 运行 task， 再 找到 这 个 当前 task 的 对 应 调度 类 
rq->curr->sched class->check preempt currl(rq, p, sync); 


F 


不 同 于 早期 的 Linux 2.6 内 核 , 那 时 只 要 配置 了 内 核 抢 占 , 一 旦 唤醒 了 一 个 高 优先 级 的 
task， 当 前 task 不 由 分 说 直接 被 拖 下 处 理 器 ， 现 在 的 内 核 将 这 个 工作 交 给 调度 类 。 
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static inline void check preempt curr(struct rq *rq, struct task struct *p, 
int sync) 
{ 

rq->curr->sched class->check preempt currl(rq, p, sync); // 由 调度 类 来 决定 
} 


// 先 看 RT 调度 类 ， 事 实 上 RT 调度 类 与 Linux 2.6 早期 的 调度 策略 很 相似 
static void check preempt curr rt (struct rq *rq, struct task struct *p, int 


sync) 


{ 
/* 被 抢占 task 如 果 是 rt task， 处 理 比 较 干脆 利落 ， 管 你 抢占 task 属于 什么 调度 类 ， 只 看 你 的 
优先 级 ， 如 果 被 唤醒 task 小 于 当前 task 的 prio (prio 越 小 优先 级 越 大 ) */ 
if (p->prio < rq->curr->prio) { 
// 告 诉 内 核 当 前 task 需要 拉 下 处 理 器 
resched task (rq->curr); 
return; 


: 

/* 青 看 Fair 调度 类 的 情况 */ 

static void check preempt wakeup(struct rq *rq, struct task struct *p, int 
sync) 


{ 


// rt task 要 来 抢占 cfs 里 的 当前 task 
if (unlikely(rt prio(p->prio))) { 
resched task (Curr) 
return; 


} 


/* 到 了 这 里 说 明 抢 占 task p 不 属于 RT 调度 类 ， 正 常情 况 下 task p 就 应 该 属于 Fair 调度 
类 了 。 如 果 是 Idle 调度 类 的 task， 显 然 当前 内 核实 现 不 允许 其 抢占 Fair 调度 类 。 但 是 如 
果 又 写 了 一 个 调度 类 ， 而 这 个 task p 就 属于 这 个 新 的 调度 类 呢 ? 所 以 如 果 要 再 加 一 个 新 的 调 
度 类 ， 而 且 希 望 能 够 抢占 Fair 里 的 task， 就 需要 改动 这 里 了 */ 

if (unlikely(p->sched class != &fair sched class)) 


return; 


// 到 了 这 里 无 论 是 抢占 task 还 是 被 抢占 task 都 属于 Fair 了 


/* 如 果 当 前 task 重新 调度 位 已 经 被 置 位 ， 那 就 不 用 管 了 ， 返 回 。 其 实 这 给 了 在 Fair 调度 类 
task 被 抢占 的 一 个 灵活 机 制 ， 在 这 种 情形 下 ， 如 果 确认 这 个 task 的 确 需要 被 换 下 ， 那 么 在 
中 断 处 理 函 数 中 直接 将 其 置 位 好 了 ，Fair 调度 类 本 身 会 依从 这 个 策略 */ 


全 (test tsk need resched(curr)) 


return; 
/* 如 果 抢 占 task 的 调度 策略 不 是 NORMAL， 不 用 理 ， 直 接 返回 */ 
if (unlikely(p->policy != SCHED NORMAL) ) 
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return; 
// 如 果 当 前 task 的 调度 类 是 IDLE， 换 掉 它 
if (unlikely(curr->policy == SCHED IDLE)) { 
resched task(curr); 
return; 
} 
/*OK， 既 然 内 核 的 调度 策略 就 不 允许 这 种 WAKEUP 时 的 抢占 ， 那 就 没什么 事 了 ， 返 回 */ 
if (!sched feat (WAKEUP PREEMPT)) 


return; 


/* 内 核 的 调度 策略 允许 这 种 WAKEUP， 当 前 内 核 状 态 满足 重新 调度 条 件 ， 置 位 */ 
if (sched feat (WAKEUP OVERLAP) && (sync || 
(se->avg overlap < sysctl] sched migration cost && 
pse->avg overlap < sysctl sched migration cost))) { 
resched task (curr); 
return; 
} 
find matching sel(&se, &pse); 
/* 根 据 自 己 调度 策略 ， 而 不 是 仅仅 比较 prio 大 小 来 决定 抢占 task 是 否 更 需要 占有 cpu*/ 
if (wakeup preempt entity(se, pse) == 1) 
resched task(curr); 


再 看 Idle 调度 类 ， 这 个 比较 简单 ， 这 里 最 好 说 话 ， 直 接 退 让 。 


static void check preempt curr idlel(struct rq *rq, struct task struct *p, 


int sync) 


{ 


} 


resched task (rq->idle); 


需要 说 明 的 是 ， 在 这 些 调 度 类 的 static void check_preempt_curr(.….) 函 数 里 ， 并 没有 直 
接 切换 task， 这 个 时 候 还 在 中 断 处 理 函 数 中 ， 而 且 保 护 的 代码 段 还 没 执 行 完 。 所 以 这 时 仅 
仅 是 将 当前 task 的 重新 调度 位 置 位 。 


static void resched task(struct task struct *p) 


{ 


} 


set tsk_ need resched(p); // 置 位 task 的 flags 重新 调度 位 


到 了 这 里 中 断 处 理 程序 完成 了 自己 的 工作 ， 也 唤醒 了 需要 唤醒 task， 到 了 中 断 处 理 程 


序 退 4 


的 时 候 。 如 下 是 内 核发 生 中 断 时 的 代码 分 析 : 


irq svc: 


svc entry 


#ifdef CONFIG PREEMPT // 内 核 被 配置 为 可 抢占 
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get thread info tsk // 找 到 当前 task 的 struct thread info 指针 
ldr r8， [tsk，#TI_PREEMPT] // 把 preempt _count 放 到 寄存 器 r8 里 
add r7, r8, #1 @ increment it // 中 断 本 身 也 是 不 能 被 抢占 的 
str r7, [tsk, #TI PREEMPT] 

#endif 
irq handler // 中 断 处 理 函数 ， 唤 醒 另 一 个 task， 当 前 置 位 需要 调度 
// 中 断 从 这 里 退出 


#ifdef CONFIG PREEMPT 
// 恢 复 中 断 前 的 当前 task 的 preempt_count 


str r8, [tsk, #TI PREEMPT] @ restore preempt count 
// 取 出 当前 task 的 TI_FLAGS 

ldr r0, [tsk, #TI FLAGS] @ get flags 

// 先 看 一 下 当前 task 的 preempt_count 是 否 为 0 

teq r8, #0 @ if preempt count != 0 


/* 如 果 preempt_count 不 为 0,r0 被 置 0, 说 明 无 论 如 何不 能 被 抢占 ,如 果 preempt_count 
不 为 0，r0 就 是 task 的 TI_FLAGS， 如 果 被 置 位 了 _TIF_NEED_RESCHED 将 会 导致 抢占 发 
生 。 代 码 转 向 svc_preempt， 所 以 这 就 是 为 什么 在 代码 段 中 加 上 preempt_disable() 和 
preempt_enable () 能 起 到 保护 不 被 抢占 的 原因 */ 
movne r0, #0 @ force flags to 0 
tst r0, # TIF NEED RESCHED 
blne svc_preempt 

#endif 
ldr r0, [sp, #S_PSR] @ irqs are already disabled 
mar Spar cxsf; TO 


// 恢 复 之 前 或 的 状态 

ldmia py x0 = pel” @ load r0 - pc, cpsr 
UNWIND ( .fnend ) 
ENDPROC(_ irq svc) 


这 里 ， 中 断 返 回 了 ， 受 保护 的 代码 继续 运行 ， 当 受 保护 的 代码 运行 完 遇 到 了 


preempt_enable()。 这 里 抢占 真实 发 生 了 ， 另 外 一 个 task 被 推 上 处 理 器 。 


// 开 抢占 

#define preempt enable() \ 

dof{\ 
preempt_ enable no_resched(); \ // 这 里 将 自己 加 在 preempt_count 的 1 减 掉 
barrier(); \ // 内 存 屏 蔽 
preempt check resched(); \ 

} while (0) 


// 调 度 时 机 检测 

#define preempt check resched() \ 

dof{f\ 
if (unlikely (test thread flag (TIF NEED RESCHED)))\ 看 一 下 自己 是 否 需 
新 调度 
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preempt schedule(); \ // 抢 占 
} while (0) 
// 抢 占 调度 
asmlinkage void _sched preempt schedule (void) 
{ 
// 取 出 struct thread info 指针 
struct thread info *ti = current thread info(); 
/* 检 查 preempt_count 和 中 断 是 否 被 禁止 。 这 两 个 情况 任何 一 个 发 生 都 不 能 抢占 。 在 
Linux 2.6 后 期 的 内 核 里 ， 处 理 器 中 断 被 禁止 也 是 不 可 抢占 状态 */ 
if (likely(ti->preempt count || irqs disabled())) 
return; 
dof{ 
// 将 自己 置 位 被 抢占 了 
add_ preempt count (PREEMPT ACTIVE); 
/* 进 入 调度 器 ， 调 度 器 会 选择 比 自己 更 适合 task 来 运行 ， 当 前 task 被 拉 下 处 理 器 */ 
schedule ()，; 
/* 当 被 抢占 掉 task 又 获得 了 运行 机 会 ， 从 这 里 重新 开始 */ 
sub_preempt_ count (PREEMPT ACTIVE); 


} while (need resched()); 


, 
3. 普通 的 内 核 态 抢 占 


需要 禁止 抢占 的 内 核 代码 毕竟 是 少数 ， 大 部 分 情况 下 ， 内 核 是 没有 禁止 抢占 的 ， 这 时 
与 上 文 不 同 的 是 在 中 断 返 回 时 ， 走 到 了 svc_preempt。 


svc_preempt: 
//1r 里 保存 的 就 是 上 一 条 指令 blne svc_preempt 的 下 一 个 地 址 
mov r8, lr 
// 跳 到 asmlinkage void _sched preempt schedule irq(..) 
1: bl preempt schedule irq @ irq en/disable is done inside 
/* 又 一 次 获得 运行 机 会 ， 青 次 检查 是 否 需要 调度 ， 如 果 需 要 ， 还 是 要 让 出 CPU。 从 获得 运行 机 会 到 
这 里 ， 可 能 新 的 中 断 又 发 生 了 。 所 以 要 再 次 检查 */ 


ldr r0, [tsk, #TI_ FLAGS] @ get new tasks TI_FLRAGS 
tst r0, # TIF NEED RESCHED 
// 返 回 
moveq pc, r8 @ go again 
b 1 


asmlinkage void _sched preempt schedule irq(void) 
{ // 取 出 当前 task 的 struct thread info 
struct thread info *ti = current thread info(); 


dof{ 
// 标 志 自 己 被 抢占 
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add preempt count (PREEMPT ACTIVE); 
// 打 开 中 断 
local irq enable(); 
// 进 入 调度 器 切换 
schedule(); 
// 关 闭 中 断 
local irq disable(); 
// 清 除 自己 的 被 抢占 位 
Sub _ preempt count (PREEMPT ACTIVE); 
barrier (); 
} while (need resched()); 


} 

值得 一 提 的 是 ， 在 这 种 状态 下 被 抢占 task 换 下 CPU 时 ， 其 内 核 栈 存放 着 中 断 到 来 时 
自己 的 context， 所 以 再 次 获得 CPU 时 ， 要 从 先前 中 断 进 来 的 地 方 退出 去 ， 这 样 才能 退 到 
自己 原来 的 执行 地 址 。 


ava 


第 4 章 Signal 


Signal 是 系统 里 的 一 种 特殊 机 制 ， 是 指 线 程 在 从 内 核 态 切换 到 用 户 态 时 ， 脱 离 原 有 用 
户 态 执行 路 径 而 进入 预先 设置 的 Signal Handler 的 机 制 。 Signal Handler 的 前 提 发 生 在 中 断 、 
地 址 转换 异常 和 系统 调用 向 用 户 态 的 返回 ， 系 统 不 能 确定 其 准确 的 执行 时 刻 。 因 为 一 般 应 
用 获得 处 理 器 的 时 间 是 不 能 被 控制 的 , 所 以 尽管 Tick 中 断 和 定时 器 能 够 准时 到 来 并 触发 当 
前 线程 的 Signal Handler, 但 是 内 核 并 不 能 保证 应 用 线程 获得 处 理 器 ， 所 以 时 钟 中 断 并 不 能 
保证 命中 靶 心 ， 更 何况 其 他 的 随机 中 断 了 。 

Signal 处 理 与 处 理 器 架构 相关 ， 本 章 内 容 包 含 了 IWMMX 协 处 理 器 的 处 理 分 析 ， 
IWMMX 的 处 理 方式 也 适用 于 NEON 协 处 理 器 。 


4.1 信号 发 送 


信号 发 送 是 指 当 系统 中 某 个 事件 产生 时 ， 需 要 某 个 线程 的 某 个 Signal Handler 做 出 响 
应 ， 这 时 内 核 就 在 这 个 线程 的 thread info 里 做 一 个 记号 ， 待 时 机 合适 时 执行 ， 而 对 于 一 些 
严重 的 事件 ， 不 需要 用 户 态 Signal Handler 的 响应 ， 内 核 直接 就 可 以 对 响应 的 线程 做 出 
处 理 。 

// 信 号 发 送 函数 

static int _ send signal (int sig，struct siginfo *info, struct task struct *t, 


int group, int from ancestor ns) 


/* 检 查 该 信号 是 否 被 指定 的 struct task_structblock 或 ijgnore*/ 
if (!prepare signal(sig, t, from ancestor ns)) 
return 0; 


/*group 指出 了 该 信号 是 被 送 往 进程 (线程 组 ) 还 是 被 送 往 单独 的 线程 */ 


pending = group ? &t->signal->shared pending : &t->pending; 


/* 如 果 该 信号 类 型 为 小 于 SIGRTMIN 非 实时 信号 ， 且 指定 接收 对 象 已 经 接收 到 了 该 信号 ， 则 
直接 跳 过 信号 挂 载 操作 */ 
if (legacy queue (pending, sig)) 


return 0; 


/* 参 数 info 携带 的 信息 SEND_SIG_FORCED 指出 这 是 发 自 内 核 的 诸如 SIGUSR1、SIGSTOP 
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之 类 的 信号 ， 也 无 需 信 号 挂 载 操 作 */ 
if (info == SEND SIG FORCED) 
goto out set; 
// 分 配 该 信号 的 struct sigqueue 结构 ， 以 携带 该 信号 其 他 信息 
q= sigqueue alloc(sig, t, GFP ATOMIC | _GFP NOTRACK FALSE POSITIVE, 
override rlimit); 
3 tq 4 
// 挂 入 线程 组 或 线程 的 peding 队列 
list add tail(&q->list, gpending->list); 
switch ((unsigned long) info) { 
case (unsigned long) SEND SIG NOINFO: 
default: 
// 复 制 携带 的 信息 
copy_siginfo(&q->info, info); 
if (from ancestor ns) 
q->info.si pid = 0; 
break; 
} 
} else if (!is si special(info)) { 
} 
out set: 


// 设 置信 号 集 对 应 位 


sigaddset (gpending->signal, sig); 


/* 评 估 最 终 接 受信 号 的 线程 、 设 置信 号 pending 标志 、 唤 醒 接收 信号 线程 等 操作 。 人 参见 下 文 */ 


complete signal (sig, t, group); 
return 0; 


static void complete signal(int sig, struct task struct *p, int group) 


E 


struct signal struct *signal = p->signal; 


struct task struct *t; 


/* 

评价 指定 的 接收 线程 是 不 是 该 信号 的 合适 目标 线程 ， 其 评价 标准 如 下 : 如 果 信号 被 指定 线程 
block, 或 者 指定 线程 正在 结束 生命 , 或 者 指定 线程 被 debug, 或 者 指定 线程 当前 不 占用 处 理 
器 ， 或 者 指定 线程 有 pending 没 被 处 理 的 signal， 那 么 指定 线程 都 不 是 该 信号 合适 的 接收 
体 。 这 里 避 开 指定 线程 当前 不 占用 处 理 器 情况 的 原因 在 于 普通 信号 的 执行 时 机 必定 是 从 内 核 态 
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向 用 户 态 返 回 的 路 上 ， 如 果 不 是 当前 线程 其 信号 执行 必定 会 遭 到 延迟 ， 所 以 尽量 选择 占用 处 理 
器 的 线程 。 而 避 开 有 pending signal 的 指定 线程 则 是 为 了 使 信号 执行 更 加 均匀 ， 不 至 于 
都 堆 在 一 个 线程 上 
*/ 
if (wants signal (sig, p)) 
t=p; 
else if (!group || thread group empty (p)) 
/* 若 要 寻找 另外 合适 的 线程 ， 则 对 象 的 目标 必须 是 发 往 线程 组 ， 如 果 不 是 线程 组 ， 直 接 
返回 ， 因 为 对 于 单一 线程 的 进程 。 若 其 占用 处 理 器 且 已 经 置 位 了 TIF_SIGPENDING 
就 不 需要 唤醒 该 线程 了 */ 


return; 


else { 
/* 
搜寻 线程 组 里 的 线程 ， 找 到 合适 线程 
*/ 
t = signal->curr target; 
while (!wants signal(sig, t)) { 
t = next thread(t); 
if (t == signal->curr target) 
/* 遍 寻 线程 组 , 找到 的 线程 已 经 被 其 他 信号 选择 过 了 , 这 里 不 需要 进一步 对 其 
做 TIF_SIGPENDING 置 位 或 者 唤醒 操作 了 ， 因 为 上 一 次 的 信号 发 送 过 程 
已 经 做 过 了 */ 
return; 
} 
// 找 到 合适 的 线程 


signal->curr target = t; 


if (sig fatal(p, sig) && 
!(signal->flags & (SIGNAL UNKILLABLE | SIGNAL GROUP EXIT)) && 
!sigismember (&t->real blocked, sig) && 
(sig == SIGKILL 11 
!tracehook consider fatal signall(t, sig))) { 


if (!sig kernel coredump(sig)) { 
/*SIGQUIT、SIGILL、SIGTRAP、SIGABRT、SIGBUS 等 信号 发 生 ， 杀 死 整 个 线程 组 */ 


return; 


上 


/* 
对 指定 线程 置 位 TIF_SIGPENDING 唤醒 TASK_INTERRUPTIBLE 睡眠 状态 的 指定 线程 
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*/ 
signal wake up(t, sig == SIGKILL); 


return; 


42 信号 执行 


如 上 文 所 述 ，Signal 执行 时 机 是 其 从 内 核 返回 用 户 态 时 。 在 该 task 的 返回 途径 上 ， 内 
核 会 检查 是 否 有 pending 的 signal 没有 处 理 ， 如 果 有 signal pending， 则 执行 信号 处 理 。 内 
核 为 Signal 处 理 函 数 执行 需要 做 如 下 几 项 工作 。 

(1) 找到 pending 了 哪个 信号 。 

(2) 从 内 核 态 返回 用 户 态 的 路 上 势必 要 弹 掉 该 task 以 前 的 用 户 态 context,， 所 以 内 核 要 
把 其 保存 下 来 。 

(3) 改变 从 普通 的 内 核 态 返回 用 户 态 的 路 径 ， 铺 设 一 条 能 够 返回 到 Signal 处 理 函 数 的 
路 径 。 

(4) Signal 处 理 函数 还 是 用 该 task 的 用 户 栈 ， 只 是 这 个 栈 最 新 的 frame 是 被 内 核 杜 撰 
出 来 的 假 环 境 。 


4.2.1 路 径 切 换 


在 中 断 返 回 、 系 统 调用 返回 的 路 径 中 ， 最 后 一 项 工作 是 检测 当前 线程 是 否 有 待 处 理 的 
信号 ， 如 果 确 有 信号 pending， 则 中 断 返 回 用 户 态 的 路 径 ， 进 入 信号 执行 。 
/* 在 Signal pending 时 被 中 断 返回 、 系 统 调用 返回 调用 ， 这 里 标志 着 信号 Handler 执行 工作 
正式 开始 */ 


asmlinkage void do notify resume (…) 


{ 


// 进 入 该 函数 的 参数 regs 指向 当前 栈 项 ， 这 里 是 内 核 栈 保 持 用 户 态 context 地 方 
if (thread flags & _TIF SIGPENDING) // 检 查 当前 task 是 否 有 信号 pending 
do signal (gcurrent->blocked, regs, syscall); 


} 


static int do signal (sigset t *oldset, struct pt regs *regs, int syscall) 


{ 


// 通 过 检查 保存 的 cspr 的 后 四 位 来 确定 regs 是 否 指 对 了 
if (!user mode (regs)) 


return 0; 


// 休 眠 操作 
if {try to freeze()) 
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goto no signal; 
single step clear(current); 


// 找 出 到 底 是 pending 了 那 种 信号 


signr = get signal to deliver(&info, &ka, regs, NULL); 


no_signal: 
// 这 一 部 分 参见 系统 调用 重 入 


return 0; 


4.2.2 ARM Linux 下 信号 执行 环境 的 搭建 


Signal Handler 的 执行 不 同 于 向 用 户 态 代码 段 的 返回 ， 那 里 有 着 保存 完好 的 寄存 器 状 
态 ， 有 着 完整 栈 轨迹 ， 弹 回去 接着 跑 即 可 。 但 是 Signal Handler 虽然 是 一 段 编译 好 的 代码 ， 
但 是 进入 时 处 理 器 的 寄存 器 状态 却 需要 杜撰 出 来 ,而且 内 核 也 要 确保 其 执行 完 能 够 调 回 来 ， 
所 以 要 为 其 准备 栈 内 容 。 

//Signal Handler 执行 环境 的 准备 

static void handle _ signal (…) 


{ 


/* 若 处 在 系统 调用 ， 需 检查 系统 重 入 情况 ， 参 见 下 文 */ 
if (syscall) { 

Switch (regs->ARM r0) { 

Case -ERESTART RESTARTBLOCK: 

case -ERESTARTNOHAND: 


Case -ERESTARTSYS: 


Case -ERESTARTNOINTR: 


// 信 号 处 理 函数 的 运营 环境 的 搭建 主要 在 这 里 进行 
if (ka->sa.sa flags & SA SIGINFO) 

ret = setup rt frame (usig, ka, info, oldset, regs); 
Slses 


ret = setup frame (usig, ka, oldset, regs); 
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为 了 搭建 信号 处 理 函数 的 运行 环境 ， 内 核 使 用 了 如 下 结构 (这 是 位 于 task 用 户 态 的 


stack 上 ): 


stru 


ct sigframe { 
struct ucontext uc; 


unsigned long retcode[2]; 


struct ucontext { 


// 堆 


unsigned long uc flags; 
struct ucontext *#uc_l1ink; 
Stack 七 uc stack; 

// 存 放 task 以 前 用 户 态 的 context 
struct sigcontext uc mcontext; 
sigset t uc _ sigmask; 


unsigned long uc_regspace[128] attribute (( aligned (8))); 


栈 搭建 


static int setup frame (int usig, struct k sigaction *ka, sigset t *set, 


struct pt_ regs *regs) 


t 


// 首 先 找到 task 用 户 栈 ， 然 后 从 用 户 栈 再 分 配 出 sizeof (*frame) 的 空间 
struct sigframe _user *frame = get sigframe (ka, regs, sizeof (*frame)); 
err |= setup sigframe (frame, regs, set); 
if (err == 0) 
err = setup return(regs, ka, frame->retcode, frame, usig); 


return err; 


/* 这 里 需要 把 内 核 栈 里 保存 的 task 用 户 态 contex 保存 在 struct sigcontext uc mcontext 里 */ 


Static int 
setup sigframe (struct sigframe _user *sf, struct pt regs *regs, sigset 七 


*set) 


{ 


// 保 存 寄存 器 
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_ Put user error(regs->ARM r0, g&sf->uc.uc mcontext.arm r0, err); 


put user error(regs->ARM r1，&sf->uc-uc mcontext.arm rl1l, err); 


_ Put user error(regs->ARM r8, &sf->uc.uc mcontext.arm r8, err); 


_ Put user error(regs->ARM cpsr, &sf->uc.uc mcontext.arm cpsr, err); 


// 保 存 线程 相关 状态 
_ Put user error(current->thread.trap no, &sf->uc.uc mcontext.trap no, 
err); 


_ Pput user error(set->sig[0], &sf->uc.uc mcontext.oldmask, err); 
err |= _ copy to user(&sf->uc.uc sigmask, set, sizeof (*set)); 


// 保 存 marvell IWMMXT 协 处 理 器 conetxt 
#ifdef CONFIG IWMMXT 
0 && test thread flag(TIF USING IWMMXT)) 
err |= preserve iwmmxt context (&aux->iwmmxt); 
#endif 


1£ err 


// 这 里 保存 arm vfp 协 处 理 器 conetxt 


#ifdef CONFIG VFP 
if (err == 0) 
err |= vfp save state(&sf->aux.vfp); 
#endif 
_Put user error(0, &aux->end magic, err); 


return err; 


/ /搭建 跳 转 路 径 
static int setup return(struct pt regs *regs, struct k sigaction *ka, 


unsigned long _ user *rc, void _user *frame, int usig) 


// 内 核 记录 的 信号 处 理 函数 的 入 口 地 址 

unsigned long handler = (unsigned long)ka->sa.sa handler; 

unsigned long retcode; 

int thumb = 0; 

/* 将 cspr 的 条 件 状 态 位 清 零 ，ARM 指令 是 条 件 执行 的 ， 既 然 信号 处 理 函数 是 不 依赖 以 前 的 状 
态 ， 自 然 需要 将 条 件 状态 位 清 零 */ 

unsigned long cpsr = regs->ARM cpsr & ~PSR f; 


if (ka->sa.sa flags & SA THIRTYTWO) 
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cpsr = (cpsr & ~MODE MASK) | USR MODE; 


// 这 里 略 去 thumb 指令 方式 下 的 处 理 


if (ka->sa.sa flags & SA RESTORER) { 
// 如 果 设 置 了 信号 处 理 函 数 返回 内 核 的 地 址 ， 就 优先 用 
retcode = (unsigned long)ka->sa.sa restorer; 
} else { 
unsigned int idx = thumb << 1; 


/ ” /如果 设置 了 SA_SIGINFO， 选 择 下 面 邦 个 入 口 
if (ka->sa.sa flags & SA SIGINFO) 
idx += 3; 


if (_ put user(sigreturn codes[idx], rc) 11 
_ Pput user(sigreturn codes[idx+1], rc+1)) 
return 1; 


if (cpsr & MODE32 BIT) { 


/* 如 果 是 普通 signal，idx 为 零 ， 选 择 第 一 个 入 口 点 ; 
如 果 是 rt signal，idx 为 3 左 移 2 位 等 于 12， 正 好 是 第 二 个 入 口 点 */ 
retcode = KERN SIGRETURN CODE + (idx << 2) + thumb; 

} else { 


//Thumb 指令 方式 下 的 处 理 ， 这 里 不 分 析 


} 


// 作 为 信号 处 理 函 数 的 参数 

regs->ARM r0 = usig; 

// 信 号 处 理 函 数 新 栈 

regs->ARM sp = (unsigned long)frame; 

// 返 回 入 口 地 址 ， 放 到 1r， 等 到 信号 处 理 函 数 返回 时 使 用 
regs->ARM lr = retcode; 

// 信 号 处 理 函 数 的 入 口 地 址 

regs->ARM pc = handler; 

// 条 件 状态 位 清 零 后 的 cspr 


regs->ARM cpsr = cpsr; 


return 0; 
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4.2.3 Signal 处 理 函 数 的 返回 


Signal 处 理 函 数 执行 完毕 之 后 需要 返回 到 内 核 态 ， 为 了 迎接 其 返回 ， 内 核 做 了 如 下 
安排 。 
内 核 在 异常 向 量 表 +0x00000500 的 地 方 放置 了 内 核 返 回 入 口 : 


const unsigned long sigreturn codes[7] = { 
MOV_R7_NR SIGRETURN, SWI_SYS_SIGRETURN, SWI_THUMB SIGRETURN, 
MOV_R7_NR RT SIGRETURN, SWI_SYS RT _ SIGRETURN, SWI_ THUMB RT _ SIGRETURN, 
}; 


这 是 一 个 若干 指令 组 成 的 数组 , 该 数组 在 void _init early_trap_init(..….) 中 和 异常 向 量 表 
一 起 被 复制 到 最 终 位 置 。 检 查 该 数组 发 现 ， 其 中 的 指令 其 实 是 软 中 断 调用 ， 可 见 信号 处 理 
函数 返回 内 核 借 助 于 软 中 断 调用 。 再 者 内 核 中 准备 了 两 个 系统 调用 asmlinkage int 
sys_sigreturn(...)，asmlinkage int sys_rt_sigreturn(.….) 用 来 处 理 异常 向 量 表 +0x00000500 处 的 
2 个 软 中 断 调 用 。 

asmlinkage int sYs_sigreturn(struct Pt_regs *regs) 


struct sigframe _user *frame; 


current thread info()->restart block.fn = do no restart syscall; 


if (regs->RRM sp & 7) 
goto badframe; 


// regs->ARM_sp 是 信号 处 理 函 数 的 栈 


frame = (struct sigframe _ user *)regs->ARM sp; 


// 由 于 其 在 用 户 态 ， 需 要 做 一 次 检查 
if (!access ok(VERIFY READ, frame, sizeof (*frame))) 


goto badframe; 
// 恢 复 task 进入 信号 处 理 函 数 之 前 的 用 户 态 
再 站 (restore sigframe (regs, frame)) 


goto badframe; 


return regs->ARM r0; 


} 


/* 因 为 在 launch 异常 处 理 函 数 之 前 就 把 task 的 用 户 态 context 做 了 保存 ， 所 以 到 了 取出 的 
时 候 */ 
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static int restore sigframe (Struct pt regs *regs, struct sigframe _user 
*sf) 


* 


struct aux sigframe user *aux; 
sigset t set; 


int err; 


/* 除 了 task 用 户 态 的 context， 当 前 task 的 信号 blocked 屏蔽 位 图 也 被 保存 ， 从 用 户 态 
内 存 拷贝 恢复 */ 
err = copy from user(&set, &sf->uc.uc sigmask, sizeof (set)); 
if (err == 0) { 
sigdelsetmask (&set, ~ BLOCKABLE); 
spin lock irq(&current->sighand->siglock); 
current->blocked = set; 
recalc_ sigpending (); // 重 新 计算 当前 是 否 可 以 清楚 信号 pending 位 
spin unlock irq(&current->sighand->siglock); 
} 
// 以 下 就 是 恢复 task 的 用 户 态 context 
__ get user error(regs->ARM r0, &sf->uc.uc mcontext.arm r0, err); 
_ get user error(regs->ARM rl, &sf->uc.uc mcontext.arm rl1l, err); 


_ get user error(regs->ARM sp, &sf->uc.uc mcontext.arm sp, err); 
_ get user error(regs->ARM lr, &sf->uc.uc mcontext.arm lr, err); 
__ get user error(regs->ARM pc, &sf->uc.uc mcontext.arm pc, err); 
_ get user error(regs->ARM cpsr, &sf->uc.uc mcontext.arm cpsr, err); 


err |= !valid user regs (regs); 


// 这 里 保存 的 是 特殊 的 诸如 协 处 理 器 的 context 


aux = (struct aux sigframe _ user *) sf->uc.uc regspace; 


/* 恢 复 IWMMX 协 处 理 器 context， 对 于 CA9 则 需要 处 理 Neon 的 context， 内 核 在 切换 、 信 和 号 


等 方面 对 Neon 的 处 理 方式 与 IWMMX 协 处 理 器 相同 */ 


#ifdef CONFIG IWMMXT 


if (err == 0 && test thread flag (TIF USING IWMMXT)) 


err |= restore iwmmxt context (&aux->iwmmxt); 


#endif 


} 


return err; 


由 于 又 恢复 task 用 户 态 到 内 核 栈 ， 所 以 当 内 核 从 这 里 返回 的 时 候 顺 着 铺 好 的 内 核 栈 就 
自然 而 然 的 弹 回 到 中 断 或 者 系统 调用 前 的 用 户 态 地 址 。 
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4.2.4 系统 调用 重 入 


关于 系统 调用 重 入 有 以 下 两 种 情况 。 

(1) 信号 被 屏蔽 或 者 被 忽略 ， 这 时 不 需要 执行 信号 处 理 函 数 。 

(2) 需要 执行 信号 处 理 函 数 。 

先 看 第 一 种 ， 若 某 个 系统 调用 被 打 断 ， 它 返回 时 必 会 以 如 下 错误 代码 返 
如 果 以 block 方式 重启 : -ERESTARTNOHAND 

如 果 以 重新 调用 方式 重启 : -ERESTARTNOHAND,， -ERESTARTSYS, -ERESTARINOINTR 


static int do signal(sigset t *oldset, struct pt regs *regs, int syscall) 


{ 


| 


// 人 参见 signal 处 理 函 数 执行 


no_signal: 


// 如 果 是 从 系统 调用 过 来 的 
if (syscall) { 
if (regs->ARM r0 == -ERESTART RESTARTBLOCK) { 


/*Thumb 指令 集 的 处 理 ， 明 显 指令 长 度 较 短 ， 这 里 不 做 进一步 展开 */ 

if (thumb mode (regs)) { 
regs->ARM r7 = _ NR restart syscall - _ NR SYSCALL BASE; 
regs->ARM pc -= 2; 

} else { 


#if defined (CONFIG AEABI) && !defined (CONFIG OABI COMPAT) 
// AEABI 编译 器 相关 
regs->ARM r7 = _ NR restart syscall; 
regs->ARM pc -= 4; 

#else 
u32 _ user *usp; 


u32 swival = _ NR restart syscall; 


// 用 态 堆 栈 开 出 一 个 新 的 frame 
regs->RRM sp -= 12; 

// 新 的 frame 

usp = (u32 _ user *)regs->ARM sp; 


swival=swival- NR SYSCALL BASE+ NR OABI SYSCALL BASE; 
// 保 存 task 用 户 态 的 pc 值 

put user(regs->ARM pc, &usp[0]); 

// 将 一 个 对 系统 调用 restart_syscall 的 指令 压 栈 

/* swi _NR restart syscall */ 

put user (0xef000000 | swival, gusp[1]); 

// 把 如 下 指令 压 栈 


110 拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 


/* ldr pc, [sp], #12 */ 
put user (0xe49df00c, gusp[2]); 
// 改 变 了 代码 段 ， 需 要 更 新 icache 
flush icache range( (unsigned long)usp, 
(unsigned long) (usp + 3)); 
/* 这 一 行 最 重要 ， 当 回 到 用 户 态 时 ，pc 的 指针 指向 产生 软 中 断 的 那 条 指令 地 址 */ 
regs->ARM pc = regs->ARM sp + 4; 


#endif 


if (regs->ARM r0 == -ERESTARTNOHAND || 
regs->ARM r0 == -ERESTARTSYS || 
regs->ARM r0 == -ERESTARTNOINTR) { 


// 参 见 下 文 的 setup_syscall restart 分 析 
setup syscall restart (regs); 


} 
single step set (current); 
return 0; 

} 

// 用 户 态 Context 的 修改 


static inline void setup syscall restart(struct pt regs *regs) 


{ 
regs->ARM r0 = regs->ARM ORIG r0; 

/* 把 用 户 态 pc 指针 后 退 一 格 ， 正 好 指向 swi 发 生前 的 地 址 ， 将 导致 原 系统 调用 被 重新 调用 */ 
regs->ARM pc -= thumb mode (regs) ? 2 : 4; 

} 


重 入 口 的 定义 如 下 : 


SYSCALL DEFINEO (restart syscall) 
. 


struct restart block *restart = gcurrent thread info()->restart block; 
// 重 新 开始 没有 完成 的 工作 


return restart->fn(restart); 


Paya Er 人 人 
第 $ 章 ”进程 与 进程 内 存 
内 核 最 大 的 意义 是 将 蛮荒 的 硬件 世界 改造 成 文明 的 进程 、 线 程 社会 。 


5.1 Linux 进程 


5.1.1 Fork 


笔者 年 轻 时 只 关注 内 核 ， 那 时 觉 着 Linux 的 先 Fork 再 Exec 机 制 太 拖泥带水 ， 一 步 创 
建 全 新 进程 的 机 制 才 够 动 ， 应 该 抛弃 老 进程 ， 直 接 为 一 个 新 进程 构造 一 个 全 新 的 环境 。 在 
研究 完 Android 操作 系统 之 后 才 明 白 ，Fork 机 制 才 是 构建 大 型 操作 系统 的 重要 基石 ， 若 内 
核 不 支持 资源 继承 的 进程 创建 机 制 ， 是 无 法 或 者 很 难 构建 大 型 操作 系统 的 。 

(1) Fork 第 一 个 重要 工作 是 管理 资源 继承 ， 这 里 面包 括 文件 、 信 号 、 虚 拟 内 存 等 方面 
的 资源 。 其 中 虚拟 内 存 的 处 理 方式 不 同 ， 将 导致 是 产生 新 的 进程 还 是 当前 进程 内 线程 ， 以 
及 新 老 进 程 之 间 的 关系 。 

Fork 机 制 中 关于 诸如 文件 、 信 号 等 方面 的 资源 处 理 对 内 核 的 后 续 影响 比较 直接 ， 本 书 
不 进行 展开 ， 而 关于 虚拟 内 存 的 处 理 ， 本 书 以 Android Java 进程 为 例 在 下 文 分 析 。 

(2) Fork 机 制 的 另 一 个 重要 工作 为 新 进程 的 第 一 个 线程 指定 内 核 态 的 起 始 地 址 ， 从 而 
为 新 进程 建立 的 运行 轨迹 ， 由 于 新 进程 的 第 一 个 线程 运行 的 时 刻 都 是 从 第 一 次 被 调度 处 理 
器 开始 ， 该 时 刻 处 于 内 核 态 ， 然 后 顺 着 继承 而 来 栈 弹 到 Fork 调用 的 下 一 条 地 址 ， 当 然 那 已 
经 是 新 进程 的 虚拟 内 存 空间 了 。 

新 进程 的 第 一 个 线程 生命 的 第 一 时 刻 是 在 调度 器 里 开始 的 ， 其 内 核 起 始 路 径 的 指定 是 
通过 修改 线程 的 内 核 切换 context 且 准备 一 个 新 的 没有 老 线程 运行 轨迹 的 内 核 栈 来 完成 的 ， 
代码 实现 如 下 : 


Int copy_thread (unsigned long clone flags, unsigned long stack start, 
unsigned long stk sz, struct task struct *p, struct pt regs *regs) 
{ 
struct thread info *thread = task thread info(p); 
// 内 核 栈 的 栈 底 存放 着 对 应 线程 用 户 态 的 context 
struct pt regs *childregs = task pt regs (p); 


*childregs = *regs; 

// 子 进程 

childregs->ARM r0 = 0; 

/* 用 户 态 堆栈 ， 对 于 新 进程 这 就 是 老 进程 的 用 户 栈 ， 对 于 同一 进程 的 新 线程 ， 线 程 库 在 这 里 存 
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放 新 的 线程 入 口 */ 
childregs->ARM sp = stack start; 
// 情 况 切 换 context 
memset (gthread->cpu context, 0, sizeof (struct cpu context save)); 
// 设 置 新 进程 或 线程 的 内 核 栈 
thread->cpu context.sp = (unsigned long)childregs; 
// 设 置 新 进程 或 线程 的 内 核 运行 起 点 


thread->cpu context.pc = (unsigned long)ret from fork; 


return 0; 


} 


往 后 新 线程 逐步 退出 内 核 态 ， 转 向 用 户 态 的 执行 clone 调用 的 后 一 条 地 址 。 这 是 用 户 
态 起 始 地 址 的 设置 是 由 线程 库 实现 的 ， 关 于 线程 库 的 实现 请 参考 Android 部 分 。 

新 进程 继承 了 老 进 程 虚拟 地 址 ， 自 然 就 继承 其 了 用 户 栈 ， 其 转向 用 户 态 的 第 一 条 执行 
地 址 即 为 老 进程 做 Fork 调用 的 下 一 地 址 。 


5.1.2 ”Exec 新 进程 创建 


在 Android 系统 里 Exec 机 制 虽然 没有 Fork 机 制 那么 重要 ， 但 却 是 系统 中 必 不 可 少 的 
组 成 部 分 。 因 为 除了 基于 Java 进程 ， 系 统 中 还 有 诸如 init、 硬 件 设备 用 户 层 deamon 之 类 
的 进程 大 量 存在 。 

新 进程 创建 分 为 以 下 两 个 主要 方面 。 

(1) 脱离 老 进程 的 Context，Linux 内 核 没 有 提供 直接 创建 一 个 新 进程 的 机 制 ， 所 有 的 
新 进程 都 是 从 上 一 个 被 Fork 出 来 进程 演进 过 来 ， 所 以 新 进程 首先 释放 老 进 程 虚拟 地 址 空 
间 、 关 闭 老 进程 打开 的 文件 、 消 灭 老 进程 里 除 当 前 线程 之 外 的 线程 等 工作 。 

(2) 打开 新 进程 的 二 进 制 镜像 、 为 新 进程 准备 最 初 的 运行 栈 、 找 出 新 进程 的 动态 链接 
器 并 MAP 之 、 为 新 进程 建立 虚拟 地 址 空间 、 设 置 新 进程 用 户 态 起 跑 点 …… 

//Exec 构建 新 进程 环境 的 主体 

static int load elf binary(struct linux binprm *bprm, struct pt_ regs *regs) 


{ 
elf phdata = kmalloc(size, GFP KERNEL); 


// 将 二 进 制 ELF 镜像 的 头 读 进来 
retval = kernel read(bprm>file, loc->elf ex.e phoff; 
(char *)elf phdata, size); 


/*GCC 连接 的 时 候 会 把 使 用 的 动态 连接 器 文件 路 径 放 在 ELF 里 ， 这 里 扫描 ELF 找到 动态 连接 器 */ 
for (i = 0; i < loc->elf ex.e phnum; i++) { 


// 检 查 这 一 段 是 否 PT_INTERP， 如 果 是 PT _INTERP 表示 这 里 藏 着 动态 连接 器 
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if (elf ppnt->p type == PT INTERP) { 


// elf interprete 将 存放 路 径 字 符 串 
elf interpreter = kmalloc(elf ppnt->p filesz, 
GFP KERNEL); 


// 将 路 径 读 进 elf interpreter 

retval = kernel read(bprm->file, elf ppnt->p offset, 
elf interpreter, 
elf ppnt->p filesz); 


/* 打 开动 态 连接 器 文件 ， 对 于 Android 就 是 /system/bin/1linker, 对 与 ubuntu 
就 是 /1ib/1d-x.x.x.so*/ 


interpreter = open exec(elf interpreter); 


/* 读 取 动 态 连接 器 二 进 制 镜像 上 的 BINPRM_BUF_SIZE 一 段 到 bprm->buf， 动 
态 链接 器 其 实 也 是 ELF 文件 ， 其 实 就 是 把 其 ELF 头 读 进来 */ 
retval = kernel read(interpreter, 0, bprm->buf, 
BINPRM BUF SIZE); 


/* Get the exec headers */ 
loc->interp elf ex = * ((struct elfhdr *)bprm->buf); 
break; 

i 

elf ppnt++; 


elf ppnt = elf phdata; 
// 可 见 是 不 是 可 执行 栈 是 由 编译 时 决定 的 
for (i = 0; i < loc->elf ex.e phnum; i++, elf ppnt++) 
if (elf ppnt->p type == PT _ GNU _ STACK) { 
if (elf ppnt->p flags & PF X) 
// 可 执行 栈 
executable stack = EXSTACK ENABLE XxX; 
else 
// 不 可 执行 栈 ，Androidq 的 二 进 制程 序 属于 这 种 情况 
executable stack = EXSTACK DISABLE _X7 


break; 


if (elf interpreter) { 
// 这 里 对 动态 链接 器 进行 检查 ， 略 去 


} 
// 和 过 去 的 自己 说 再 见 ， 下 文 详细 分 析 
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retval = flush old exec (bprm) 


// 还 是 和 过 去 的 自己 说 再 见 而 且 为 新 进程 命名 ， 在 下 文 详细 分 析 


setup new exec (bprm); 


// 设 置 新 进程 的 启动 参数 ， 攒 出 新 进程 的 最 初 的 用 户 栈 
retval = setup_ arg pages (bprm, randomize stack top(STACK TOP), 
executable stack); 


current->mm->start stack = bprm->p; 


/* 把 二 进 制程 序 镜像 ELF 的 PT_LORD 虚拟 地 址 映射 出 来 ， 在 Android 系统 中 以 system/bin/ 
app_process 为 例 , 该 镜像 的 结构 可 以 使 用 "prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/ 
bin/arm-eabi-readelf -a out/target/product/generic/system/bin/app process 
"dump 出 来 ， 其 Program Headers 结构 节选 如 下 : 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align 
PHDR 0x000034 0x00008034 0x00008034 0x000e0 0x000e0 R 0x4 
INTERP 0x000114 0x00008114 0x00008114 0x00013 0x00013 R 0x1 
[Requesting program interpreter: /system/bin/linker] 

LOAD 0x000000 0x00008000 0x00008000 0x01194 0x01194 R E 0x1000 
LOAD 0x002000 0x0000a000 0x0000a000 0x001b0 0x001c0 RW 0x1000 
DYNAMIC 0x002040 0x0000a040 0x0000a040 0x000e8 0x000e8 RW 0x4 
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0 
EXIDX 0x00114c 0x0000914c 0x0000914c 0x00048 0x00048 R 0x4 


其 中 的 INTERP 类 型 的 段 就 是 存放 动态 链接 器 路 径 的 ， 这 个 没有 MAP 出 来 ， 而 是 使 用 文件 read 操 
作 读 取出 来 了 ， 而 其 中 两 个 LOAD 类 型 的 段 ， 其 起 始 地 址 分 别 位 于 0x00008000 和 0x0000a000。 
下 面 内 核 需 要 将 这 两 个 段 MAP 出 来 */ 


for(i = 0, elf ppnt = elf phdata; 
i < loc->elf ex.e phnum; i++, elf ppnt++) { 
int elf prot = 0, elf flags; 
unsigned long k, vaddr; 
// 找 PT_LOAD 类 型 的 段 ， 别 的 不 管 
if (elf ppnt->p type != PT_LOAD) 


continue; 


// 每 一 次 MAP 之 前 都 要 看 是 不 是 要 做 brk 
if (unlikely (elf brk > elf bss})) { 
unsigned long nbyte; 
retval = set brk(elf bss + load bias, 
elf brk + load bias); 


} 


第 5 章 ”进程 与 进程 内 存 Li 


} 
/* 检 索 该 段 的 属性 ， 并 记录 在 elf_prot 中 ， 这 个 要 在 MAP 时 使 用 */ 
if (elf ppnt->p flags & PF R) 
elf prot |= PROT READ; 
if (elf ppnt->p flags & PF W) 
elf prot |= PROT WRITE; 
if (elf ppnt->p flags & PF X) 
elf prot |= PROT EXEC; 


elf flags = MAP PRIVATE | MAP DENYWRITE | MAP EXECUTABLE; 


vaddr = elf ppnt->p vaddr; 

if (loc->elf ex.e type == ET EXEC || load addr set) { 
//0x00008000 和 0x0000a000 两 个 段 都 是 到 这 
elf flags |= MAP FIXED; 

} else if (loc->elf ex.e type == ET DYN) { 


} 
/*MAP 动作 ， 这 里 仅仅 跟 进 程 持 上 struct vm_area _struct 描述 结构 ， 没 有 页 表 页 
目录 操作 ， 要 等 到 程序 运行 产生 也 异常 才 会 发 生 */ 
error = elf map (bprm->file, load bias + vaddr, elf ppnt, 
elf proty elf flagsy 0)s 


// 结 果 检 查 


/* 这 里 要 做 工作 是 把 动态 链接 器 的 需要 MAP 出 来 的 段 MAP 出 来 ， 后 面 详细 分 析 */ 


if (elf interpreter) { 


unsigned long uninitialized varl(interp map addr); 


elf entry = load elf interp(&loc->interp elf ex, 
interpreter, 
&interp map addr, 


load bias); 


/* 对 于 Android 系统 的 system/bin/linker， elf entry 返回 值 为 0*/ 


if (!IS ERR((void *)elf entry)) { 


/* elf_entry 是 整个 程序 用 户 态 的 入 口 地 址 ， 然 而 它 却 不 在 程序 二 进 制 的 虚拟 空 
间 上 ， 而 是 在 动态 连接 器 的 入 口 点 上 ， 对 于 system/bin/app _process， 其 
ELF 头 的 1oc->interp_elf ex.e_entry 里 面 记 录 了 这 个 入 口 点 的 地 址 : 
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0x b0001000*/ 
interp load addr = elf entry; 


elf entry += loc->interp elf ex.e entry; 


} else { 


// 新 进程 struct cred 初始 化 

install exec creds (bprm) ; 

// 代 码 数据 段 起 始 结束 地 址 在 这 里 设置 

/* N.B. passed fileno might not be initialized? */ 
current->mm->end code = end code; 
current->mm->start code = start code; 
current->mm->start data = start data; 
current->mm->end data = end data; 
Current->mm->start stack = bprm->p; 


/* 为 新 进程 准备 用 户 态 的 返回 点 ， 新 进程 一 直 使 用 Exec 之 前 的 内 核 栈 在 忙活 ， 然 后 它 顺 着 个 内 核 
栈 往 回 跑 ， 知 道 要 返回 用 户 态 时 ， 其 pc 被 指向 了 新 的 地 址 ， 用 户 栈 也 被 换 掉 了 ， 所 以 当 其 Exec 
之 后 第 一 次 返回 用 户 态 时 就 走向 了 新 生 。 这 里 要 做 的 是 : 

(1) 设置 其 用 户 态 pc 地 址 -动态 链接 器 的 入 口 地 址 。 

(2) 设置 用 户 栈 的 地 址 ， 动 态 链接 器 要 根据 这 个 最 初 的 用 户 栈 地 址 找到 启动 参数 ， 找 到 二 进 制程 序 
的 入 口 点 

*/ 


start thread(regs, elf entry, bprm->p); 


} 


动态 链接 器 的 加 载 类 似 于 二 进 制 镜像 的 加 载 ， 也 是 要 MAP PT_LOAD 类 型 的 段 ， 以 
Android 的 system/bin/linker 为 例 分 析 。 首 先 使 用 命令 : prebuilt/linux-x86/toolchain/ 
arm-eabi-4.4.3/bin/arm-eabi-readelf -a out/target/product/generic/system/bin/linker dump system/ 
bin/linker 的 结构 ， 其 Program Headers 节选 如 下 : 


Program Headers: 


Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align 
LOAD 0x0000d4 0x00000000 0xb0000000 0x00000 0x00000 R 0x1000 
LOAD 0x001000 0xb0001000 0xb0001000 Ox0adcc 0x0adcc R E 0x1000 
LOAD 0x00c000 0xb000c000 0xb000c000 0x006fc Ox0b4d0 RW 0x1000 
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0 


EXIDX 0x00ba84 0xb000ba84 0xb000ba84 0x00348 0x00348 R 0x4 
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可 见 要 MAP 出 0xb0001000 和 0xb000c000 这 两 个 段 。 其 中 0xB0001000 是 
system/bin/linker 的 基地 址 ， 也 是 其 入 口 处 ,参见 其 makefile 文件 bionic/linker/Android.mk: 


LINKER TEXT BASE := 0xB0001000 


关于 system/bin/linker 的 实现 参见 Android 章节 ， 本 节 着 重 于 内 核 机 制 的 分 析 。 动态 链 
接 器 的 加 载 在 函数 static unsigned long load elf interp(…) 里 进行 , 与 程序 二 进 制 镜像 加 载 非 
常 相似 ， 可 参见 程序 二 进 制 镜像 加 载 ， 不 再 歼 述 。 


5.2 CPU 与 MMU 


配备 MMU 的 处 理 器 是 复杂 系统 运行 的 关键 ， 虚 拟 内 存 的 重要 性 在 计算 机 体系 结构 里 
的 作用 无 论 怎么 强调 都 不 算 过 分 。 虚 拟 内 存 机 制 的 贡献 在 于 解决 如 下 两 大 问题 。 


1 内存 碎片 的 困扰 


一 个 复杂 应 用 跑 起 来 经 常 做 的 动作 是 什么 ? 是 内 存 的 申请 和 释放 。 一 旦 一 块 内 存 被 占 
用 ， 意 味 着 该 内 存 块 之 前 之 后 的 内 存 被 分 割 开 。 随 着 应 用 的 复杂 度 增 加 ， 内 存 被 严重 地 碎 
片 化 ， 导 致 系统 后 来 很 难 找 的 合适 长 度 内 存 以 满足 应 用 的 需要 。 


2. 大 量 的 内 存 浪费 


在 没有 虚拟 内 存 的 支持 的 系统 下 ， 所 有 的 内 存 操作 都 是 真实 的 物理 内 存 ， 而 且 每 次 申 
请 都 需要 最 大 限度 满足 需要 ， 申 请 一 个 16K 的 栈 ， 无 论 栈 空 栈 满 都 要 提前 满足 ， 如 果 只 分 
配 8 区 ， 等 到 栈 到 8K 的 时 候 ， 后 面 的 物理 内 存 可 能 已 经 无 法 使 用 了 《碎片 化 或 者 被 占用 )。 
加 载 一 个 二 进 制 镜像 时 需要 全 部 加 载 进 内 存 ， 不 然 当 跑 到 代码 段 页 面 异 常 时 ， 系 统 是 无 法 
请 页 的 。 


5.2.1 ARM Linux 页 表 页 目录 结构 


32 位 处 理 器 的 MMU 的 页 表层 次 通常 为 两 级 , ARM V7 也 不 例外 , 有 些 叫 法 为 页 目录 、 
页 表 , 为 了 简单 起 见 称 之 为 Ll 页 表 工 2 页 表 。 为 了 对 于 两 级 页 表 的 处 理 器 在 其 页 表 定 义 文 
件 arch/arm/include/asm/pgtable.h 中 包含 文件 革 nclude <asm-generic/4level-fixup.h>， 该 文件 
屏蔽 了 三 级 页 表 的 操作 。 

基本 页 表 操作 定义 如 下 : 

/* 索 引 虚 拟 地 址 addr 对 于 的 L1 页 表 项 */ 

#define pgd offset(mm, addr)  ((mm)->pgd + pgd index (addr)) 


/* 在 ARM 32 位 架构 下 ， 该 宏 直 接 定义 为 L1 的 页 表 项 */ 
#define pud alloc(mm, pgd, address) (pgd) 
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/*PMD 操作 对 ARM 32 位 无 效 ， 在 ARM 32 位 体系 下 #define pud none (pud) 0, #define 
pmd offset (dir, addr) ((pmq 七 *) (dir) ) ， 所 以 该 宏 直接 返回 pud*/ 
#define pmd alloc (mm, pud, address) \ 
((unlikely(pgd none(* (pud))) && _pmd alloc(mm, pud, address))? \ 
NULL: pmd offset (pud, address)) 


在 ARM Linux 系统 中 有 两 种 页 表 结构 ， 一 种 是 3G 以 上 的 一 级 页 表 ， 一 种 是 上 一 节 提 
到 的 二 级 页 表 。 前 者 是 内 核 态 的 寻 址 方式 ， 是 静态 的 。 后 者 是 应 用 虚拟 地 址 使 用 寻 址 方式 ， 
是 动态 的 。 

Linux 操作 系统 从 3G 开始 , 把 虚拟 地 址 沿 着 物理 内 存 的 开始 , 一 直 映 射 到 物理 内 存 的 
边界 (这 就 是 Linux 系统 上 物理 内 存 超过 1G 遇 到 诸多 问题 的 原因 ， 不 在 于 处 理 器 转换 不 
了 ， 而 是 OS 设计 的 问题 )。 这 部 分 页 表 只 起 到 虚拟 地 址 到 物理 地 址 转换 的 作用 ， 通 常 不 产 
生 异 常 。 为 了 节省 转换 时 间 ， 提 高 TLB 利用 率 ，Linux 内 核 借助 ARM MMU 的 1M 段 转换 
项 ， 直 接 在 L1 级 页 表 中 转换 物理 地 址 。 

3G 以 下 的 地 址 采用 上 节 提 到 的 二 级 页 表 模 型 ,不 过 为 了 使 得 ARM MMU 能 够 在 Linux 
的 虚拟 内 存 框架 下 工作 ， 做 了 如 下 设计 : 

在 Linux 虚拟 内 存 模型 下 ， 需 要 记录 页 面 的 dirty、 可 读 、 可 写 等 属性 。 但 是 ARM L2 
的 页 表 项 的 结构 并 不 能 跟 Linux 的 要 求 一 一 对 应 , 而 且 L2 页 表 项 又 被 硬件 全 部 占 满 。 所 以 
对 于 每 个 L2 页 表 ，Linux 准备 了 两 份 ， 一 份 给 Linux 用 ， 一 份 给 硬件 MMU 用 。 其 组 织 结 
构 是 在 一 个 4K 大 小 的 页 面 上 。 

256 项 页 表 项 的 Linux 页 表 0|256 项 页 表 项 的 Linux 页 表 1|256 项 页 表 项 的 MMU 页 表 
0|256 项 页 表 项 的 MMU 页 表 1 

这 样 每 次 分 配 L2 的 页 表 必 须 分 配 两 个 ， 代 码 分 析 如 下 : 

/*L2 页 表 的 分 配 与 挂 接 ，mm 为 当前 task 的 struct mm_struct，vma 为 异常 虚拟 地 址 对 应 的 

虚拟 内 存 描述 结构 , pmd 对 于 ARM 32 位 就 是 L1 的 页 表 项 , address 为 发 生 异 常 的 虚拟 地 址 */ 
int _ pte _alloc(struct mm struct *mm, struct vm area struct *vma, 
pmd t *pmd, unsigned long address) 
{ // 分 配 12 页 表 


patable t new = pte alloc one (mm, address); 


/分 本 完 了 L2 页 表 ， 下 面 要 把 L2 页 表 挂 载 在 L1 对 应 的 页 表 项 中 ， 对 当前 进程 的 页 表 进 行 操 
作 ， 这 时 别 的 处 理 器 上 的 或 者 当前 处 理 器 上 发 生 抢占 的 当前 进程 里 其 他 的 线程 可 以 也 会 发 生 
页 异常 , 而 且 地 址 可 能 跟 address 在 同一 个 4K 里 (对 于 ARM 是 同一 个 8K) 将 会 产生 冲突 ， 
所 以 要 锁 住 page_table lock */ 

spin lock(g&mm->page table lock); 


/* 检 查 一 下 对 应 的 L1 是 否 已 经 被 填 上 ， 从 发 生 异 常 到 锁 住 page_table_lock 这 段 时 间 可 能 
有 个 哥们 已 经 把 活 干 完了 ， 如 果 是 这 样 那 就 省 事 了 ， 把 分 配 的 页 表 释 放 掉 即 可 */ 
if (likely(pmd none(*pmd))) { /* Has another populated it ? */ 
mm->nr ptestt+; 


/* 把 L2 挂 到 Ll 上 */ 
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pmd populate (mm, pmd, new); 
new = NULL; 

} else if (unlikely (pmd trans splitting (*pmqd)))//ARM32 位 不 考虑 这 种 情况 
wait split huge page = 1; 

/* 开 锁 */ 

spin unlock (gmm->page table lock) 

/* 对 应 从 发 生 异 常 到 锁 住 page_table_lock 这 段 时 间 另 外 的 线程 已 经 修复 了 页 表 ， 把 申请 

的 页 表 释 放 掉 */ 


if (new) 


pte free(mm, new); 


return 0; 
} 
/* 把 工 2 挂 到 LL1*/ 
static inline void _pmd populate (Pmd t *pmdp，Phys_addr t pte, 


unsigned long prot) 


/* pte 是 分 配 4K 大 小 的 内 存 的 物理 地 址 ， 前 2K 留 给 Linux 使 用 。PTE_HWTABLE_OFF 
=512x4，prot 是 属性 信息 */ 
unsigned long pmdval = (pte + PTE HWTABLE OFF) | prot; 
/* pmdval 执行 了 MMU 硬件 使 用 的 页 表 ， 填 到 工 1 的 页 表 项 */ 
pmdp[0] = __ pmd (pmdval); 
/* L2 的 页 表 项 数目 是 256， 往 下 再 拉 256 项 ， 指 向 第 二 张 页 表 */ 
pmdp[1] = _ pmd(pmdval + 256 * sizeof (pte t)); 
flush pmd entry (pmdp); 
} 


在 内 核 需 要 设置 L2 的 页 表 项 时 ， 调 用 如 下 函数 : 


extern void cpu set pte ext(pte t *ptep, pte t pte, unsigned int ext); 
#define cpu_set pte ext (ptep,pte,ext) processor.set pte ext (ptep,pte, ext) 


可 见 最 终 ，L2 页 表 项 的 设置 是 架构 相关 支持 代码 ， 位 于 proc-xx.S 中 ，v7 架构 相关 代 
码 如 下 : 


/*R0 里 存放 内 核 页 表 项 地 址 ，R1 里 存放 内 核 页 表 项 值 ，R2 指出 硬件 版 本 页 表 项 值 的 第 11 位 属 
性 值 */ 
ENTRY (cpu_v7_set pte ext) 
#ifdef CONFIG MMU 
/* 直 接 写 入 内 核 使 用 的 页 表 项 信息 ， 这 仅 能 够 被 Linux 内 核 访 问 到 ，ARM MMU 不 会 使 用 */ 
| @ linux version 
/* 根 据 内 核 使 用 页 表 项 信息 ， 配 置 硬件 使 用 的 页 表 项 与 ARM 处 理 的 MMU 有 着 复杂 灵活 的 配置 
和 使 用 ，Linux 不 可 能 把 其 所 有 的 功能 都 发 挥 出 来 (事实 上 任何 一 种 操作 系统 的 ARM 处 理 
器 实现 也 只 需 且 只 是 利用 其 部 分 功能 )。 关 于 ARM MMU 协 处 理 器 的 研究 本 书 不 做 展开 ， 感 
兴趣 的 读者 请 参见 infocenter.arm.com */ 
bic r3, rl, #0x000003f£0 
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bic r3, r3, #PTE TYPE MASK 
vr Ty LE3; Ee 
orr r3, r3, #PTE EXT APO | 2 


tst rl, #1 << 4 
orrne r3, r3, #PTE EXT TEX(1) 
//Dirty 属性 的 设置 
Bor Yl1; Tl; #L PTE DIRTY 
tst rl, #L PTE RDONLY | L PTE DIRTY 
orrne r3, r3, #PTE EXT APX 
// 特 权 级 属性 的 设置 
tst rl, #L PTE USER 
orrne Ir3, r3, #PTE EXT RAP1 
/* 内 核 配 置 决 定 了 是 否 使 用 ARM MMU 的 domain 机 制 */ 
#ifdef CONFIG CPU USE DOMAINS 
tstne  r3, #PTE EXT APX 
bicne  r3, r3, #PTE EXT APX | PTE EXT APO 
#endif 
// 执 行 属性 的 设置 
tst rl, #L PTE XN 
orrne Ir3, r3, #PTE EXT XN 


tst rl, #L PTE YOUNG 
tstne rl, #L PTE PRESENT 
moveq  r3, #0 
/* 将 硬件 使 用 的 页 表 项 值 写 入 L2 的 页 表 项 ， 这 里 是 可 以 被 ARM 的 MMU 从 L1 索引 过 来 */ 
RARM str r3 [r0; #2048]! ) 
THUMB( add r0, r0, #2048 ) 
THUMB( str r3, [r0] ) 
mer pl Di E07 El e100, 1 @ flush pte 
#endif 
mov pe, 1r 
ENDPROC (cpu_v7_set pte ext) 


5.2.2 ”页 表 页 目录 的 建立 


页 异常 的 发 生 有 两 种 可 能 : 一 种 是 应 用 虚拟 地 址 对 应 物理 页 的 缺 页 、 访 问 异常 ， 这 属 
于 缺 页 与 请 页 机 制 的 范畴 :一 种 是 页 表 页 目录 转换 过 程 的 异常 ， 这 种 异常 导致 是 由 页 表 页 
目录 建立 的 。 本 节 讨 论 后 面 一 种 。 
/* 该 函数 用 于 Linux generic 的 异常 处 理 ， 支 持 多 种 架构 和 多 种 应 用 环境 ， 里 面 不 被 Android + 
Arm CA9 使 用 的 代码 都 以 斜体 处 理 。 该 函数 的 主要 作用 是 1 L2 页 表 项 的 索引 与 建立 ， 并 把 属 
于 最 后 一 级 页 表 项 的 异常 引 向 缺 页 与 请 页 机 制 */ 


int handle mm fault(sStruct mm struct *mm, struct vm area struct *vma, 


/* 


第 5 章 ”进程 与 进程 内 存 


unsigned long address, unsigned int flags) 
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因为 这 里 是 抽象 的 Linux 虚拟 内 存 异 常 处 理 ， 要 支持 各 种 处 理 器 架构 ， 在 某 些 64 位 的 处 理 器 
架构 下 表达 到 3、4 级 ， 这 就 是 如 下 4 个 页 表 项 指针 定义 的 原因 ， 但 是 在 ARM 32 位 下 ， 前 三 


个 都 是 退化 1 页 表 项 */ 
pgd t *pgd; 
pud t *pud; 
pmd 七 *pmd; 
pte t *pters 


/*HUGETLB_PAGE 通过 加 大 页 面 的 颗粒 度 ， 从 而 提高 TLB 的 命中 率 ， 在 当前 CA9 架构 下 的 


Android 系统 不 考虑 这 个 应 用 */ 
if (unlikely(is_ vm hugetlb page (vma))) 
return hugetlb fault (mm, vma, address, flags); 


pgd = pgd offset (mm, address); 
pud = pud alloc (mm, pgd, address); 
if (!pud) 


return VM FAULT OOM; 
pmd = pmd alloc (mm, pud, address); 
if (!pmd) 
return VM FAULT OOM; 
/* Transparent Hugepages 依赖 X86 系统 ， 与 Arm Android 无 关 */ 
if (pmd none(*pmd) && transparent hugepage enabled(vma)) { 
if (!vma->vm_ ops) 
return do_ huge pmd anonymous page (mm vma, address, 
pmd, flags); 
} else { 
pmd t orig pmd = *pmd; 
Darrierf) > 
/* 仍 然 是 Transparent Hugepages 相关 ， 不 考虑 */ 
if (pmd trans huge(orig pmd)) { 
if (flags & FAULT FLAG WRITE &é& 
!pmd write (orig pmd) && 
!pmd_trans_ splitting (orig pmqd)) 
return do huge pmd wp page (mm, vma, address, 
pmd, orig pmd); 
return 0; 


/* 


如 果 工 1 的 页 表 项 不 存在 ， 则 要 创建 L2 页 表 ， 并 将 其 挂 到 L1 的 页 表 项 ， 对 于 ARM 32 位 L2 


页 表 是 成 对 分 配 的 
*/ 
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各 (unlikely (pmd_ none (*pmd) ) && _Pte alloc(mm, vma, pmd, address)) 
return VM FAULT OOM; 

/* if an huge pmd materialized from under us just retry later */ 

if (unlikely (pmd trans huge (*pmd))) 
return 0; 

/* 

找到 该 虚拟 地 址 对 应 的 L2 的 页 表 项 ， 这 里 取出 的 是 L2 的 Linux 页 表 项 

*/ 

pte = pte offset map(pmd, address); 

return handle pte fault (mm, vma, address, pte, pmd, flags); 

} 


L2 页 表 的 索引 如 下 : 


#define pte offset map (pmd,addr) (_ pte map(pmd) + pte index(addr)) 

/* 尽 管 L1 页 表 项 指向 4K 的 后 半 段 ， 但 是 这 里 是 取得 4K 页 对 齐 ， 再 取 映 射 的 虚拟 地 址 ， 所 以 又 
到 页 起 始 边界 上 */ 

#define _ pte map (pmd) (pte 七 *)kmap atomic(pmd page(* (pmd))) 


加 


/* 虚 拟 地 址 除 以 4K 得 出 是 第 几 页 ， 再 与 上 512-1， 得 出 自己 的 在 这 连续 的 两 个 L2 页 表 的 索引 


位 置 */ 
#define pte index (addr) (((addr) >> PAGE SHIFT) & (PTRS_ PER PTE-1)) 
内 核 为 Linux 使 用 的 L2 页 表 定 义 了 如 下 属性 : 
#define L PTE PRESENT (AT(pteval t, 1) << 0) 


#define L PTE YOUNG (_AT(pteval t, 1) << 1) 


#define L PTE SHARED (_AT(pteval t, 1) << 10)/* shared(v6),coherent (xsc3) 
.A 


MMU 硬件 使 用 的 L2 页 表 项 完全 满足 ARM 硬件 规范 ， 定 义 如 下 : 


#define L PTE MT UNCACHED ( AT(pteval t, 0x00) << 2) /* 0000 */ 
#define L PTE MT BUFFERABLE (_RT(pteval t, 0x01) << 2) /* 0001 */ 
#define L PTE MT WRITETHROUGH (_AT(pteval t, 0x02) << 2) /* 0010 */ 


#define L PTE MT DEV_ CACHED ( AT(pteval t, Ox0b) << 2) /* 1011 */ 
#define L PTE MT MASK (_AT (pteval t, 0x0f) << 2) 


5.3 ”进程 虚拟 内 存 


5.3.1 Android 进程 虚拟 内 存 的 继承 


进程 虚拟 内 存 空间 包括 内 核 态 空间 和 用 户 态 空 间 。 其 中 内 核 态 地 址 空间 是 所 有 进程 的 
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共享 页 表 页 目录 。 这 里 研究 的 是 用 户 态 虚 拟 内 存 空间 的 创建 ， 而 且 专 指 在 Android 系统 中 
的 Java 进程 。 

Dalvik 首先 通过 Fork 机 制 复制 DVM 虚拟 机 , 然后 基于 Android Application framework 
加 载 相关 的 .so、activity、service*…… ， 于 是 Android Java 进程 就 诞生 了 。 


/*Fork 机 制 关于 进程 虚拟 内 存 空 间 处 理 函数 ， 参 数 unsigned long clone flags， 指 明了 是 
创建 新 进程 还 是 新 线程 ， 参 数 struct task struct * tsk 是 新 的 进程 或 线程 */ 
static int copy mm(unsigned long clone flags, struct task struct * tsk) 


{ 


/*Android 进程 Fork 的 clone_ flags 参数 是 0x11, 而 DVM 线 程 Fork 的 clone flags 
参数 是 0x 450f00*/ 


if (clone flags & CLONE VM) { 
/* CLONE_VM 定义 为 #define CLONE VM 0x00000100。 而 DVM Fork clone flags 


是 0x 450f00, 所 以 DVM 的 线程 创建 走 到 这 里 , 可 见 对 于 线程 创建 , struct mm_struct 
和 页 表 页 目录 上 压根 就 是 共享 的 ， 当 然 要 引用 计数 的 增加 */ 
atomic inc(&oldmm->mm users); 
mm = oldmm; 
goto good mm; 
} 
/*DVM 进程 创建 clone_flags 是 0x11， 走 到 这 里 ， 进 行 著名 的 dup_mm (…) 操作 。 创 建 一 
个 新 的 进程 ， 为 其 准备 一 个 新 的 struct mm_struct 结构 ， 见 下 文 */ 
retval = -ENOMEM; 
mm = dup_ mm(tsk); 


// 新 进程 与 其 struct mm_struct 结构 匹配 起 来 
tsk->mm = mm; 

tsk->active mm = mm; 

return 0; 


} 


/* 虚拟 内 存 空 间 的 框架 函数 为 新 的 进程 创建 其 虚拟 地 址 空间 ， 这 包括 虚拟 机 地 址 转换 机 构 页 表 页 
目录 及 虚拟 地 址 段 的 描述 结构 struct vm_area_struct 的 继承 与 创建 。 新 老 进 程 最 大 的 不 
同 在 于 其 数据 段 的 完全 隔离 与 新 生 ， 所 以 这 里 最 值得 关注 的 是 COW 的 处 理 */ 

struct mm struct *dup mm (Struct task struct *tsk) 


{ 


/* 给 新 进程 分 配 struct mm _struct 结构 */ 


mm = allocate mm(); 


/* 新 进程 的 struct mm struct 和 struct task struct 建立 关系 */ 
if (!mm init(mm, tsk)) 


goto fail nomem; 
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/*struct vm_area_struct 链表 和 页 表 页 目录 的 复制 就 在 这 里 完成 */ 
err = dup mmap (mm, oldmm); 


} 
/* 虚 拟 地 址 段 struct vm area struct 的 复制 */ 


static int dup mmap(struct mm struct *mm, struct mm struct *oldmm) 


{ 


/* 如 果 要 对 struct vm_area_struct 链表 和 页 表 页 目录 操作 , 必 先 取 得 struct mm struct 
的 struct IW_semaphore mmap sem; */ 

down write(&oldmm->mmap sem); 

/* 前 面 一 步 保 证 了 其 他 CPU 上 不 会 再 有 改动 struct vm_area_struct 链表 和 页 表 页 目录 
操作 ， 下 一 步 要 保证 2 cache 里 的 内 容 跟 内 存 的 内 容 一 致 : flush cache*/ 

flush_cache_dup mm(oldmm) : 

// 对 新 进程 的 struct mm_struct 做 相关 的 初始 化 操作 


// 实 际 工作 在 这 里 进行 
for (mpnt = oldmm->mmap; mpnt; mpnt = mpnt->vm next) { 
struct file *file; 
/* 每 个 struct vm_area_struct 结构 代表 进程 的 一 段 虚拟 地 址 ， 逐 段 取出 当前 进程 的 
struct vm_area_struct 结构 ， 该 结构 详细 描述 了 某 段 虚拟 地 址 起 始 地 址 、 属 性 等 信息 */ 


if (mpnt->vm flags & VM DONTCOPY) { 
/* 如 果 当 前 这 段 虚拟 内 存 是 不 能 复制 的 ， 必 就 直接 跳 到 下 一 段 虚 拟 内 存 */ 
long pages = vma pages (mpnt); 
mm->total vm -= pages; 
vm stat account (mm, mpnt->vm flags, mpnt->vm file,-pages); 
continue; 
} 
charge = 0; 
if (mpnt->vm flags & VM ACCOUNT) { 
/* 该 段 地 址 属于 VM ACCOUNT 信息 关注 的 范围 。 基 本 上 这 些 分 段 地 址 都 属于 关注 
范围 */ 
unsigned int len = (mpnt->vm end - mpnt->vm start) >> PAGE SHIFT; 
if (security vm enough memory (len)) 
goto fail nomem; 
charge = len; 


} 
/* 为 新 进程 分 配 struct vm area struct 结构 */ 


tmp = kmem cache alloc(vm area cachep, GFP KERNEL); 


tmp-—>vm flags &= ~VM LOCKED; 
tmp-—>vm next = tmp->vm prev = NULL; 
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// 检 查 是 否 有 backed file 

file = tmp->vm file; 

if (file) { 
// 该 段 地 址 是 filebacked 类 型 
struct inode *inode = file->f path.dentry->d inode; 
/*struct address space *mapping 记录 了 该 file 的 page cache*/ 
struct address space *mapping = file->f mapping; 


get file (file); 

// 检 查 该 段 地 址 的 属性 

if (tmp->vm flags & VM DENYWRITE) 
atomic dec(&inode->i writecount); 

mutex lock(&mapping->i mmap mutex); 

if (tmp->vm flags & VM SHARED) 
mapping->i mmap writablet++; 

flush dcache mmap lock (mapping); 

/* 将 该 段 struct vm area_struct 和 page cache 树 链接 起 来 */ 

vma_ prio tree add(tmp, mpnt); 

flush dcache mmap unlock (mapping); 

mutex unlock (gmapping->i mmap mutex); 


/* 将 “struct vm area_struct” 结 构 挂 到 新 进程 的 链表 中 */ 
_vma link rb(mm, tmp, rb link, rb parent); 

rb link = &tmp->vm rb.rb right; 

rb parent = &tmp->vm rb; 


mm->map_count++; 
/* 这 里 进行 该 段 内 存 对 应 的 页 表 页 目录 的 复制 */ 
retval = copy_ page range (mm, oldmm, mpnt); 


// 页 表 页 目录 的 复制 函数 
int copy page range(struct mm struct *dst mm, struct mm struct *src mm, 


struct vm area struct *vma) 


// 新 老 PGD 
dst pgd = pgd offset(dst mm, addr); 
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src pgd = pgd offset(src mm, addr); 
// 按 地 址 复制 页 表 页 目录 
dof{ 
next = pgd addr end(addr, end); 
if (pgd none or clear bad(src pgd)) 
continue; 
/* 复 制 页 表 页 目录 的 层级 结构 ， 并 不 是 简单 的 复制 ， 会 根据 该 段 地 址 的 属性 进行 相关 操作 */ 
if (unlikely(copy pud range(ldst mm, src mm, dst pgd, src pgd, 
vma, addr, next))) { 
ret = -ENOMEM; 
break; 
} 
} while (dst pgd+t+, src pgd++, addr = next, addr != end); 


} 


/* 复 制 页 表 项 PTE， 即 最 小 单位 的 虚拟 地 址 复制 ， 这 里 重点 关心 COW 内 存 的 处 理 */ 
static inline unsigned long copy_one ptel(struct mm struct *dst mm, struct 
mm struct *src_ mm, 

pte t *dst pte, pte t *src pte, struct vm area struct *vma, 


unsigned long addr, int *rss) 


// 当 前 进程 和 虚拟 地 址 段 的 属性 

unsigned long vm flags = vma->vwm flags; 
pte t pte = tere pte; 

struct page *page; 


/* 
如 果 是 COW 内 存 段 , pte 复制 前 需 加 上 写 保护 , 等 于 在 Fork 这 一 时 刻 将 数据 空间 在 新 老 进程 
里 都 锁 住 了 一 样 
*/ 
if (is cow mapping (vm flags)) { 
// 锁 父 进程 数据 
ptep_ set wrprotect (src mm, addr, src pte); 
// 锁 子 进程 数据 
pte = pte wrprotect (pte); 


out set pte: 
// 设 置 到 新 进程 的 页 表 项 
set pte atl(dst mm, addr, dst pte, pte); 


return 0; 
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5.3.2 ”进程 虚拟 地 址 空间 的 获得 


进程 主要 通过 map 机 制 获得 其 虚拟 内 存 ， 而 Linux 管理 虚拟 内 存 地 址 空间 的 基本 手段 


是 通过 struct vm_area_struct 进行 分 段 管理 。 这 里 有 些 面向 对 象 的 概念 ， 相 同属 性 的 连续 虚 


拟 地 芭 


上 段 由 对 应 一 个 struct vm_area_struct 结构 ， 里 面 记录 了 该 段 地 址 的 属性 、 起 始 地 址 、 


操作 函数 等 内 容 。 当 异常 发 生 时 就 索引 到 对 应 的 struct vm_area_struct 结构 并 使 用 其 中 的 操 
作 函 数 进行 处 理 。 

这 里 值得 关注 的 是 ， 在 Linux 体系 下 虚拟 地 址 分 为 匿名 和 file backed 两 类 。 前 者 的 内 
容 只 能 存在 于 物理 内 存 中 ， 后 者 的 内 容 可 以 在 存储 设备 的 文件 上 。 一 个 基于 Linux 内 核 良 
好 架构 的 操作 系统 的 设计 需要 充分 利用 file backed 内 存 机 制 。 因 为 这 可 以 灵活 地 调整 物理 
内 存 的 使 用 情况 ,典型 的 例子 是 Android 系统 的 Dalvik 代码 段 被 fle map 到 Dalvik 进程 中 ， 
这 样 不 同 的 Dalvik 进程 可 以 共享 一 份 位 于 page cache 的 Dalvik 代码 , 而 且 对 于 被 较 少 应 用 
使 用 的 Android 类 库 占 用 物理 内 存 的 机 会 大 大 减少 。 

// 虚 拟 地 址 空间 的 获取 


unsigned long mmap region(struct file *file, unsigned long addr, 


unsigned long len, unsigned long flags, 
vm flags t vm flags, unsigned long pgoff) 


/* 

在 企图 寻找 一 个 存在 的 struct vm_area_struct 结构 并 把 当前 虚拟 地 址 段 合并 进去 的 尝试 
失败 以 后 创建 新 的 struct vm_area _struct 结构 ， 开 始 一 段 新 的 地 址 

*/ 


vma = kmem cache zalloc(vm area cachep, GFP_ KERNEL); 


// 新 的 struct vm area struct 结构 
Vma->Vvm_ mm = mm; 
// 起 始 地 址 
vma->vm_ start = addr; 
// 结 束 地 址 
vma->vm end = addr + len; 
// 记 录 诸如 堆栈 生长 方式 、cow 之 类 的 属性 
vma->vm flags = vm flags; 
// 计 算 页 表 项 时 使 用 
vma->vm page prot = vm get page prot (vm flags); 
// 文 件 map 地 址 
vma->vm pgoff = pgoff; 
INIT LIST HEAD(&vma->anon vma chain); 
//file backed 文件 的 操作 
if (file) { 
error =-EINVAL; 
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/*map 的 文件 只 能 发 生 改 动 ， 不 能 发 生 增 减 ， 若 内 存 有 此 要 求 则 无 法 做 file map 操作 */ 

if (vm flags & (VM GROWSDOWN|VM GROWSUP)) 

goto free vma; 

if (vm flags & VM DENYWRITE) { 

/* 若 内 存 是 可 写 的 但 文件 不 可 写 ， 也 不 能 发 生 映射 */ 
error = deny write access (file); 
if (error) 
goto free vma; 
Correct wcount = 1; 

} 

/* 检 查 完毕 ， 进 行文 件 map*/ 

vma->vwm file = file; 

get file(file); 

/* 如 何 map 文件 是 由 具体 的 文件 系统 决定 。 对 于 ext4 文件 系统 ， 这 里 执行 其 static 
int ext4 file mmap (…) 函 数 ， 把 该 struct vm_area_struct 的 成 员 变量 
struct vm operations_struct 设置 为 struct vm_operations_struct 
ext4 file vm ops。 对 于 struct vm operations_struct 结构 最 重要 是 提 
供 异常 处 理 函数 和 写 函 数 ， 对 于 ext4 分 别 是 int filemap fault(…) 和 int 
ext4 page mkwrite(**) */ 

error = file->f op->mmap (file, vma); 

if (error) 

goto unmap and free vma; 


} else if (vm flags & VM SHARED) { 
// 共 享 内 存 的 处 理 
error = shmem zero_setup(vma); 
if (error) 
goto free vma; 


/* 将 新 建 的 struct vm_area_struct 结构 插入 到 进程 的 struct vm _area_struct 树 中 */ 
vma link(mm, vma, prev, rb link, rb parent); 
file = vma->vm file; 
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缺 页 请 页 与 内 存 Shrink 机 制 属 于 进程 虚拟 地 址 的 一 部 分 ， 但 是 这 部 分 内 容 非常 重要 ， 
单独 提取 一 章 分 析 。 因 为 从 系统 角度 来 看 ， 内 核 的 运行 有 两 个 动力 之 源 ， 一 是 代码 执行 枢 
纽 一 一 调度 器 ， 根 据 系统 发 生 的 各 种 事件 使 得 各 种 进 线程 被 调度 或 睡眠 : 另外 一 个 是 数据 
处 理 枢 纽 一 一 缺 页 请 页 与 内 存 Shrink 机 制 。 

应 用 程序 运行 时 获取 的 内 存 都 是 虚拟 内 存 ， 不 论 用 malloc 分 配 出 多 大 的 内 存 ， 本 质 上 
不 过 就 是 struct vm_area_struct 虚拟 内 存 的 长 度 记录 的 数值 增长 而 已 ,没有 物理 内 存 的 分 配 ， 
也 没有 页 表 页 目录 的 填充 。 应 用 程序 获得 物理 内 存 的 方式 是 其 访问 到 了 malloc 分 配 内 存 地 
丝 。 在 该 段 内 存 没有 映射 到 物理 内 存 的 情况 下 发 生 了 页 异常 ， 从 而 才 会 导致 物理 内 存 的 
分 配 。 
事实 上 ， 系 统 运行 时 没有 这 么 绝对 ， 大 部 分 的 malloc 的 实现 都 是 先进 行 大 块 虚拟 地 址 
的 map 而 导致 struct vm_area_struct 的 改变 ， 再 分 割 成 进行 小 规模 的 chunck 以 满足 malloc 


即使 没有 访问 到 ， 也 有 了 对 应 的 物理 内 存 。 这 里 可 以 参见 本 书 关于 Android 系统 相关 章节 
的 分 析 。 

内 存 Shrink 是 缺 页 请 页 的 反方 向 动作 ， 其 关键 作用 是 物理 内 存 紧 张 时 决定 释放 多 少 内 
存 、 释 放 那 些 内存 、 如 何 释 放 内 存 、 释 放 掉 有 用 内 存在 请 页 时 如 何 找 回 来 。 


6.1 缺 页 与 请 页 


应 用 运行 时 产生 大 量 的 缺 页 异常 触发 系统 中 内 存 与 存储 设备 之 间 大 量 数据 交换 。 由 此 
形成 了 存储 介质 到 处 理 器 的 双向 数据 流 ， 那 么 这 个 双向 数据 流 由 如 下 节点 组 成 : 


CPU <-->VM <-->VFS<--> FS <-->Stroage 


1. 读 方向 


飞 奔 的 处 理 器 对 数据 和 指令 的 需求 产生 频繁 的 页 异常 , 这 些 页 异常 被 传送 到 VM, VM 
根据 异常 的 地 址 和 对 应 的 文件 描述 符 通 知 VFS， 把 需要 的 数据 读 到 Page cache 里 。VFS 紧 
接着 通过 具体 的 文件 系统 定位 需要 读 取 的 介质 位 置 , 然后 把 读 取 请 求 发 送 到 具体 文件 系统 ， 
最 后 由 具体 文件 系统 启动 驱动 把 数据 读 进 内 存 。 

2. 写 方向 


处 理 器 通过 VM 或 者 直接 把 数据 写 入 Page cache, 然后 CPU 马不停蹄 地 去 忙 别 的 事情 。 
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VM 跟 VFS 配合 工作 将 这 些 数据 提交 具体 文件 系统 ， 然 后 启动 设备 驱动 写 入 外 部 存储 。 
两 个 方向 的 数据 流 都 存在 越过 VM， 而 直接 操作 VFS 的 文件 读 写 路 径 ， 但 这 不 是 系统 

工作 的 主要 方式 ， 这 条 数据 流 的 主要 动力 是 缺 页 与 请 页 机 制 。 


6.1.1 File backed 虚拟 内 存 段 操作 函数 


虚拟 内 存 段 管理 结构 struct vm_area_struct 是 管理 应 用 虚拟 内 存 的 中 枢 。 当 某 段 虚拟 内 
存 由 于 没有 映射 到 对 应 的 物理 内 存 而 发 生 异 常 时 ， 要 通过 该 结构 的 int (*faulb(struct 
vm_area_struct *vma, struct vm_fault *vm 人 ;成 员 函 数 来 处 理 。 下 面 仅 分 析 Ext4 的 实现 : 

/* 第 一 个 参数 记录 了 异常 发 生 时 对 应 的 struct vm_area_struct 节点 ， 第 二 个 参数 记 了 异常 发 
生 的 虚拟 地 址 。 该 函数 的 任务 是 找到 虚拟 地 址 对 应 的 物理 页 */ 
int filemap fault(struct vm area struct *vma, struct vm fault *vmf) 


{ 


int error; 


/* 首 先 在 该 文件 的 page cache 里 寻找 */ 

page = find get page (mapping, offset); 

if (likely(page)) { 
/* 
在 该 文件 的 page cache 发 现 对 应 的 物理 页 ， 进 一 步 启动 async 预 读 。 因 为 预期 到 系 
统 很 可 能 需要 访问 接 下 来 的 文件 内 容 。 比 如 Dalvik 在 执行 代码 时 ， 很 可 能 顺 着 该 地 址 


跑 若干 页 
*/ 
do async mmap readahead(vma, ra, file, page, offset); 
} else { 
/* 没有 在 该 文件 的 page cache 发 现 对 应 的 物理 页 ， 进 一 步 启动 sync 预 读 ， 这 里 可 
能 发 生 睡 眠 */ 


do_sync mmap_ readahead(vma, ra, file, offset); 
count_ vm event (PGMAJFAULT); 
mem cgroup_count vm event (vma->vm mm, PGMAJFAULT); 
ret = VM FAULT MAJOR; 
retry find: 
/*sync 预 读 完 毕 ， 再 一 次 在 page cache 里 寻找 */ 
page = find get page (mapping, offset); 
if (!page) 
goto no_cached page; 
} 
/* 无 论 是 否 在 Page cache 找到 对 应 页 还 是 重新 启动 了 readpage 都 走 到 这 蛙 。 走 到 这 旱 的 
前 提 是 获得 了 对 应 页 ， 在 使 用 前 要 lock 该 页 */ 
if (!lock page or retryl(page, vma->vm mm, vmf->flags)) { 
Page _ cache release (page); 
return ret | VM FAULT RETRY; 
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// 记 录 下 找到 的 物理 页 ， 函 数 执行 成 功 时 从 这 里 返 
vmf->page = page; 
return ret | VM FAULT LOCKED; 


加 


no_cached page: 


/* 
Page cache 里 没有 对 应 页 ， 预 读 不 允许 或 者 也 没有 成 功 ， 这 时 启动 readpage 读 取 该 页 
*/ 


error = page cache read(file, offset); 


/* 
读 取 完毕 返回 到 retry_find 
*] 


if (error >= 0) 


goto retry find; 


} 
6.1.2 ”File backed 内 存 的 请 页 


本 节 分 析 file backed 内 存在 其 pte 为 0 时 发 生 的 页 异常 的 处 理 ， 这 种 情况 发 生 的 条 
件 为 : 
(1) file backed 内 存在 首次 被 访问 时 ， 这 时 其 只 有 struct vm_area_struct 描述 其 属性 ， 
页 表 项 还 为 空 的 状态 。 
(2) file backed 内 存在 被 shrink 掉 的 时 候 , 但 是 VM_SHARED 类 型 且 被 修改 后 的 page 
不 属于 这 种 情况 。 
/* 该 函数 的 调用 在 系统 运行 时 最 常见 ， 大 量 见 于 代码 段 访问 以 及 mapped 数据 文件 读 访问 等 */ 
static int _do fault(struct mm struct *mm, struct vm area struct *vma, 
unsigned long address, pmd t *pmd, 
pgoff t pgoff, unsigned int flags, pte t orig pte) 


// 异 常 地 址 做 页 对 齐 
vmf.virtual address = (void _user *) (address & PAGE MASK); 


/* 该 page 对 应 磁盘 上 的 文件 ， 所 以 该 page 位 置 应 该 在 该 文件 的 page cache 树 里 ， 这 里 
使 用 上 节 描 述 的 File backed 虚拟 内 存 段 操作 函数 读 取 对 应 页 */ 


ret = vma->vm ops->fault (vma, &vmf); 


/* 
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该 异常 是 在 写 操作 时 发 生 的 。 要 检查 该 虚拟 地 址 段 的 属性 ， 若 其 有 VM_SHARED 标志 ， 将 该 操 
作 交 给 具体 的 文件 系统 。 和 否则 ， 一 个 COW 发 生 了 
部 
page = vmf .page; 
if (flags & FAULT FLAG WRITE) { 
if (!(vma->vm flags & VM SHARED)) { 
/* 在 一 个 非 共享 的 虚拟 地 址 空间 发 生 了 写 操作 异常 ， 说 明 COW 发 生 了 ， 这 里 要 新 分 配 一 
个 匿名 页 ,并 把 原 有 page 的 内 容 复 制 到 这 个 新 的 匿名 页 中 , 这 里 发 生 的 时 机 是 : 某 进 
程 map 了 自己 的 某 段 数据 空间 ， 当 前 该 进程 是 第 一 次 写 访问 该 段 数据 空间 ， 或 者 这 个 
数据 空间 对 应 的 page 虽然 被 读 过 ， 但 之 后 由 于 长 时 间 不 用 被 shrink page list 
给 释放 掉 了 ， 所 以 该 进程 发 生 pte 为 0 时 的 异常 */ 
anon = 1; 
// 为 当前 进程 分 配 一 个 物理 页 ， 这 是 一 个 匿名 页 
page = alloc page vma (GFP HIGHUSER MOVABLE, 
vma, address); 


charged = 1; 

// 把 原 有 内 容 复印 到 新 的 物理 页 

copy_user_ highpage (page, vmf.page, address, vma); 

_ SetPageUptodate (page); 

} else { 

/*VM_SHARED 类 型 的 写 访问 ， 只 在 第 一 次 访问 时 走 到 这 里 ， 由 具体 的 文件 系统 来 
处 理 。 主 要 工作 是 同步 该 page 的 writeback， 且 将 该 页 page 结构 和 对 应 的 
pte 项 置 脏 ， 参 见 do_wp_page 的 分 析 */ 


if (vma->vm ops->page mkwrite) { 
tmp = vma->vm ops->page mkwrite(vma, &vmf); 
page mkwrite = 1; 


} 
} 
// 索 引 到 页 表 项 
page_table = pte offset map lock(mm, pmd, address, &pt1); 
/* 首先 检查 在 读 取 该 page 时 ， 页 表 项 是 否 发 生 改动 。 这 种 情况 发 生 在 从 异常 跑 到 这 里 的 时 

候 ， 同 一 进程 的 别 的 线程 也 访问 了 该 地 址 */ 

if (likely(pte same (*page table, orig pte))) { 

/* 页 表 项 没有 发 生 改 动 ， 没 有 别 的 线程 先 于 我 们 */ 

// 创 建 页 表 项 

entry = mk pte (page, vma->vm page prot); 

// 写 操作 发 生 对 页 表 项 置 dirty 和 write 

if (flags & FAULT FLAG WRITE) 

entry = maybe mkwrite (pte mkdirty(entry), vma); 
// 该 页 为 新 分 配 的 匿名 页 
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if (anon) { 
/* 匿 名 页 , 对 COW, 这 里 将 该 page 加 入 到 struct vm area struct 的 struct 
anon_vma *anon_vma 列表 中 ， 从 此 该 进程 的 这 页 数据 就 成 为 了 匿名 页 */ 
page add new anon rmap(page, vma, address); 
} else { 
// 该 page 被 map 到 某 进 程 虚拟 地 空间 ， 该 页 的 map 计数 增加 
page add file rmap (page); 
if (flags & FAULT FLAG WRITE) { 
// 写 一 个 文件 的 内 容 ， 脏 页 产生 
dirty page = page; 
get page (dirty page); 


3 
// 设 置 页 表 项 


set_ pte at(mm, address, page table, entry); 


/* 页 表 项 更 新 了 ， 根 据 具体 架构 来 决定 什么 时 候 需 要 手动 更 新 cache */ 
update mmu cache(vma, address, page table); 
} else { 


// 别 的 线程 先 于 我 们 完成 


out: 
if (dirty page) { 
// 脏 页 的 处 理 
struct address_ space *mapping = page->mapping; 
/* 将 脏 页 提交 到 文件 系统 ， 有 可 能 将 该 文件 对 应 设备 回 写 线程 的 唤醒 ， 参 见 相关 章节 */ 
if (set page dirtyl(dirty page)) 
page mkwrite = 1; 


unlock page (dirty page); 

put page (dirty page); 

/* 若 该 页 之 前 就 被 标志 脏 页 ， 则 检查 对 应 设备 脏 页 是 否 到 达 写 回 条 件 ， 若 条 件 满足 启动 
写 回 机 制 ， 参 见 相 关 章 节 */ 

if (page mkwrite && mapping) { 


balance dirty pages ratelimited (mapping); 


} else { 
unlock page (vmf .page); 
// 存 放 原 始 数据 的 页 ， 无 用 了 ， 释 放 掉 
if (anon) 


page cache release (vmf .page); 
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6.1.3 匿名 内 存 的 请 页 


匿名 内 存 的 请 页 有 两 种 情况 如 下 : 

(1) 首次 访问 。zero page 的 情况 在 这 里 处 理 ， 即 防止 分 配 出 来 的 page 携带 别 的 进程 
的 原 有 内 容 。MMU 隔离 了 进程 间 的 地 址 ， 如 果 在 这 里 出 现 跨 进程 内 存 访 问 的 问题 就 比较 
搞笑 了 。 

(2) 匿名 内 存 位 于 SWAP 分 区 或 文件 。 这 种 情况 类 似 于 File backed 内 存 页 被 释放 的 情 
形 ， 从 SWAP 分 区 或 文件 里 读 出 对 应 的 page， 再 挂 到 pte 上 。 因 为 这 种 情况 导致 页 面 出 现 
经 常 的 “ 脏 ” 状 态 。 而 嵌入 式 或 者 手机 系统 使 用 的 emmc、sd card 存储 介质 都 是 nand， 频 
繁 的 写 导 致 坏 块 的 产生 。 所 以 在 嵌入 式 或 者 手机 系统 通常 不 支持 SWAP 分 区 。 本 书 也 不 讨 
论 这 方面 的 内 容 。 

/* 医 名 页 的 处 理 */ 


static int do anonymous page(struct mm struct *mm, struct vm area struct 


*vma, 
unsigned long address, pte t *page table, pmd t *pmd, 


unsigned int flags) 


/* 匿名 页 的 首次 读 ， 匿 名 页 是 新 分 配 的 内 存 ， 首 次 读 在 逻辑 上 是 没有 意义 的 ， 所 以 内 核 为 其 

准备 了 一 个 特殊 的 0 页 */ 
if (!(flags & FAULT FLAG WRITE)) { 

// 直 接 用 0 页 作为 其 访问 的 目的 
entry = pte mkspecial (pfn_pte (my_zero_pfn(address)， 
vma->vm page prot)); 
// 页 表 项 
page table = pte offset map lock(mm, pmd, address, &pt1); 


// 直 接 将 0 设置 进 其 pte 
goto setpte; 
} 


/* 首 次 写 匿名 页 ， 自 然 要 为 其 分 配 一 个 物理 页 面 ,但 是 该 页 面 可 能 携带 了 其 他 进程 的 信息 ， 所 
以 这 里 不 仅 要 分 配 新 的 页 面 ， 而 且 需 要 将 该 页 面 清 0*/ 


page = alloc zeroed user highpage movable (vma, address); 
if (!page) 
goto oom; 


__ SetPageUptodate (page); 


// 新 的 pte 值 
entry = mk pte(page, vma->vm page prot); 
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if (vma->vm flags & VM WRITE) 
entry = pte mkwrite(pte mkdirty(entry)); 
//pte 指针 
page table = pte offset map lock(mm, pmd, address, é&pt1); 


// 记 录 将 该 页 面 反 向 映射 


Page add new anon rmap(page, vma, address); 


// 设 置 pte 
setpte: 
set pte at (mm, address, page table, entry); 


} 
6.1.4 COW 访问 


COW 的 访问 有 以 下 几 种 。 

(1) 上 文 提 到 的 二 进 制 镜像 的 初始 化 数据 区 , 这 种 访问 产生 时 由 其 struct vm_area_struct 
相应 异常 处 理 函 数 int (*fault)(struct vm_area_struct *vma, struct vm_fault *vm); 来 处 理 ， 在 
该 访问 发 生 后 该 page 内 存 空 间 就 变 成 了 匿名 页 。 

(2) 该 进程 Fork 出 新 的 进程 再 次 访问 该 段 数据 区 , 就 变 成 了 页 表 项 被 置 为 保护 状态 的 
写 异常 。 

(3) 新 进程 若 访问 二 进 制 镜像 的 初始 化 数据 区 未 被 老 进 程 修改 ， 则 其 仍 满足 第 一 种 情 
况 , 仍 由 struct vm_area_struct 相 应 异常 处 理 函 数 int (*faulb(struct vm_area_struct *vma, struct 
vm_fault *vm 人 ); 来 处 理 。 

(4) 新 进程 若 访问 老 进程 运行 时 新 产生 的 匿名 数据 区 ， 属 于 第 二 种 情况 。 

(5) 老 进 程 Fork 新 进程 后 访问 自己 运行 时 产生 的 匿名 数据 区 ， 因 为 老 进 程 在 Fork 时 
自己 的 页 表 项 也 被 置 为 写 保护 ， 所 以 将 发 生 新 进程 同样 的 情况 。 

第 二 种 情况 的 处 理 如 下 

/* 

仅 考 虑 该 函数 对 COW 的 处 理 

*/ 

static int do wp page(struct mm struct *mm, struct vm area struct *vma, 

unsigned long address, pte t *page table, pmd t *pmd, 
spinlock t *ptl, pte t orig pte) 


_ releases (pt1) 


// 从 页 表 项 里 找到 锁定 的 page 


old page = vm normal page(vma, address, orig pte); 


到 至 (PageAnon (old page) && !PageKsm(old page)) { 
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/* 该 page 之 前 在 Fork 已 经 被 写 保护 锁定 ， 并 被 映射 到 不 同 的 进程 中 ， 每 映射 一 次 其 
_mapcount 都 被 加 一 , 以 后 每 当 进 程 访问 一 次 该 page 对 于 的 虚拟 地 址 都 会 分 配 新 的 
Page 并 将 该 page 复制 到 新 page 中 。 而 老 的 page 都 会 从 新 访问 进程 里 被 unmap 
掉 ， 当 最 后 一 个 进程 访问 时 ， 就 没有 必要 做 复制 工作 了 ， 继 续 使 用 该 page 即 可 */ 

到 在 (reuse swap page(old page)) { 


/*pte 之 前 已 经 设置 过 ， 这 里 将 该 page 的 struct address space *mapping; 指 
针 指向 当前 struct vm area struct 的 struct anon vma *anon vma; 即 可 */ 


page move anon rmap (old page, vma, address); 


goto reuse; 


} else if (unlikely((vma->vm flags & (VM WRITE|IVM SHARED)) == 
(VM WRITEIVM SHARED))) { 


reuse: 


// 将 该 页 置 为 yong 

entry = pte mkyoung (orig pte); 

// 清 除 写 保护 

entry = maybe mkwrite(pte mkdirty(entry), vma); 

// 重 新 设置 pte 

if (ptep set access flags (vma, address, page table, entry,1)) 
update mmu cache(vma, address, page table); 


// 从 这 里 返回 
if (!dirty page) 


return ret; 


/* 
非 最 后 一 次 访问 Cow 区 域 
*/ 
Page cache get (old page); 
gotten: 


// 分 配 一 个 新 的 page 用 来 存放 COW 数据 
new_ page = alloc page vma (GFP HIGHUSER MOVABLE, vma, address); 


// 将 COW 数据 复制 过 来 
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Cow user page (new page, old page, address, vma); 


page table = pte offset map lock(mm, pmd, address, &pt1); 
if (likely(pte same(*page table, orig pte))) { 


// 创 建新 的 页 表 项 
entry = mk pte (new page, vma->vm page prot); 


entry = maybe mkwrite(pte mkdirty(entry), vma); 


// 每 做 一 次 map 都 记录 下 其 反 向 映射 

page add new anon rmap (new page, vma, address); 
/* 设置 新 的 页 表 项 */ 

set pte at notify(mm, address, page table, entry); 


if (old page) { 
/*old_page 已 不 在 当前 进程 里 ,减少 olqd_page 的 map 计数 */ 


page_remove rmap (old page); 


} else 
mem cgroup uncharge page (new page); 


6.2 内存 Shrink 


6.2.1 Shrink 操作 shrink_page_list 


Linux 内 核 使 用 了 尽 可 能 多 的 内 存 ， 当 新 的 内 存 要 求 来 临时 ， 将 原 有 占用 的 不 常用 内 
存 释 放出 去 ， 挤 出 空间 以 满足 新 的 内 存 需求 。 本 节 描 述 的 就 是 这 个 挤占 已 用 内 存 的 框架 
函数 。 

/* shrink page _1ist() 主 要 工作 步骤 是 拿 到 的 页 面 链表 page_1ist 逐一 检查 ， 尽 量 释 放 */ 

static unsigned long shrink page list(struct list head *page list, 

struct Zone *zone, 


struct scan control *sc) 


// 依 次 扫描 page_1ist 里 的 页 面 
while (!list empty(page list)) { 
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// 索 引 到 该 页 面 

page = lru to page(page list); 
// 与 page list 断 开 

list del (gpage->lru); 


/* 若 该 页 面 是 被 mlock 锁 住 的 页 面 ， 即 使 再 长 时 间 没 有 被 使 用 ， 也 不 能 被 释放 掉 ， 比 如 
这 是 一 个 实时 应 用 的 页 面 ， 若 被 释放 掉 ， 青 访问 时 需要 启动 磁盘 操作 ， 这 是 不 可 允许 
的 。 所 以 跳 过 这 种 类 型 的 页 面 */ 

if (unlikely(!page evictable (page, NULL)) 

goto cull mlocked; 


// 若 该 页 面 处 于 writeback 状态 ， 根 据 情况 等 待 其 完成 
if (PageWriteback (page)) { 
// 要 看 当前 shirnk 模式 是 否 运行 sync 等 待 ， 否 则 直接 跳 过 该 页 面 
if ((sc->reclaim mode & RECLAIM MODE SYNC) && 
may_enter fs) 
// 等 待 
wait on page writeback (page); 
else { 
unlock page (page); 
// 等 不 及 ， 跳 过 该 页 面 
goto keep lumpy; 


} 


/* 检 查 页 面 的 引用 状态 : 
(1) 若 页 面 被 映射 到 进程 的 虚拟 地 址 空间 ， 则 依次 索引 其 反 向 映射 ， 并 检查 其 对 应 的 pte 是否 被 置 
位 工 PTE YOUNG， 若 有 一 个 pte 项 被 置 位 LI PTE YOUNG， 说 明 该 页 面 新 被 访问 ， 在 清除 其 所 有 
反 向 映射 pte 的 工 _ PTE_YOUNG 后 返回 PAGEREF_KEEP 
(2) 若 该 页 面 page 本 身 被 置 位 Referenced 则 返回 PAGEREF_RECLAIM_CLEAN 
(3) 若 (1)、(2) 同时 发 生 则 返回 PAGEREF_ACTIVATE 
(4) 若 无 以 上 情况 出 现 ， 返 回 PAGEREF_RECLAIM 
*/ 


references = page check references (page, sc); 
// 只 要 该 页 面 新 被 访问 ， 都 得 到 保留 ， 跳 过 此 页 
switch (references) { 
Case PAGEREF ACTIVATE: 
// 跳 过 
goto activate locked; 
Case PAGEREF KEEP: 
// 跳 过 
goto keep locked; 
Case PAGEREF RECLAIM: 
Case PAGEREF RECLAIM CLEAN: 
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第 
; /* 继 续 处 理 该 页 */ 


/* 匿 名 页 且 没有 被 加 入 SWAP 的 管理 机 制 ,这 里 将 其 加 入 ,以便 后 面 将 该 页 sync 到 SWAP 
后 ， 再 释放 掉 */ 
if (PageAnon(page) && !PageSwapCache (Page)) { 
if (!(sc->gfp mask & _GFP IO)) 
goto keep locked; 
/* 实质 上 就 是 加 入 SWAP 设备 或 文件 的 mapping 里 。 即 struct address_space 
swapper_space 的 page tree 里 */ 
if (!add to_swap (page) ) 
goto activate locked; 


may_enter fs = 1; 


mapping = page mapping (page); 


/* 
反 向 映射 的 处 理 ， 主 要 是 解 开 MMU 的 映射 。 见 下 文 分 析 
*/ 
if (page mapped(page) && mapping) { 
Switch (try to unmap(page, TTU UNMAP)) { 


case SWAP AGAIN: 
// 没 有 成 功 解 开 ， 跳 过 此 页 
goto keep locked; 


case SWAP_ SUCCESS: 
; /* 成 功 解 开 ， 继 续 处 理 此 页 */ 


3 


} 
/* 脏 页 的 处 理 ， 用 pageout 将 其 提交 给 writeback 机 制 。 这 里 有 个 clean page 的 


动作 ， 参 见 下文 */ 
if (PageDirty(page)) { 


/* 提交 给 writeback 机 制 */ 
switch (pageout (page, mapping, sc)) { 


Case PAGE CLEAN: 
; /* 继续 处 理 该 页 */ 


140 拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 


/* 该 page 有 对 应 的 struct buffer head， 这 是 由 block 层 产 生 的 ， 用 来 映射 部 
分 page 与 磁盘 地 址 的 ， 这 里 将 其 释放 掉 */ 
if (page has private(page)) { 
// 释 放 struct buffer head 
if (!try to release page(page, sc->gfp _ mask) ) 


goto activate locked; 


} 


// 走 到 这 里 说 明 做 好 了 对 该 page 的 释放 工作 
free it: 

nr reclaimed++; 

// 加 入 free_pages， 稍 后 将 被 释放 

list add(&page->lru, &free pages); 

continue; 


// 该 页 面 不 满足 释放 条 件 ， 继 续 保留 


activate locked: 


keep_lumpy: 
// 加 入 ret_pages 链表 ， 该 页 将 得 到 保留 
list add(gpage->lru, &ret pages); 


} 


解 映射 ， 即将 所 有 映射 到 某 个 page 的 pte 都 置 0。 无 论 对 于 匿名 页 还 是 file backed 页 ， 
做 法 都 是 扫描 其 反 向 映射 链表 ， 在 对 每 个 映射 调用 try_to_unmap_one 解 映射 。 


// 解 映射 入 口 函数 
int try to unmap(struct page *page，enum ttu flags flags) 


{ 


int ret; 


if (unlikely (PageKsm(page))) 

ret = try to unmap ksm(page, flags); 
else if (PageAnon (page)) 

// 匿 名 页 解 映射 

ret = try to unmap anon (page, flags); 
else 

//file backed 页 的 解 映射 

ret = try to unmap file(page, flags); 


return ret; 
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/* 

针对 一 个 映射 做 解 映射 操作 ， 这 里 重点 关注 file backed 页 的 解 映射 

本 

int try to unmap one(struct page *page, struct vm area struct *vma, 


unsigned long address, enum ttu flags flags) 


// 找 到 相应 的 解 映射 
pte = page check address (page, mm, address, &gptl, 0); 


if (!(flags & TTU IGNORE ACCESS)) { 
// 检 查 pte 是 否 L PTE_YOUNG 且 清 除 L PTE _YOUNG 
if (ptep clear flush young notify(vma, address, pte)) { 
ret = SWAP_FAIL; 
goto out unmap; 


} 


/* 这 里 记录 下 pte 的 值 ， 并 清除 之 ， 似 乎 是 不 经 意 一 行 代码 ， 却 解 开 该 page 与 该 struct 
vm_area_struct *vma 之 间 的 映射 ， 断 开 了 struct vm area_struct *vma 所 在 虚 
拟 内 存 空间 对 该 page 的 访问 */ 

pteval = ptep clear _ flush notify(vma, address, pte); 

// 脏 的 处 理 

if (pte dirty(pteval)) 

set page dirty (page); 


if (PageHWPoison(page) && !(flags & TTU IGNORE HWPOISON)) { 
//ARM 架构 上 不 成 立 


} else if (PageAnon(page)) { 
/* 如 果 是 匿名 页 , 且 不 支持 SWAP, 则 没有 实质 的 处 理 , 若 支持 SWAP, 则 将 page 在 swap 
的 位 置 放 在 pte 里 ， 本 书 重点 分 析 Android 操作 系统 下 的 内 核 行为 ， 这 里 略 过 */ 


SwP_entry t entry = { .val = page private(page) }; 


set pte at (mm, address, pte, swp entry to _pte (entrYy) ) 
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6.2.2 Clean Page 


在 shrink page_list 将 脏 页 提交 到 block 层 之 前 ， 内 核 需 clean 该 page。 这 包括 两 方面 
动作 , 一 是 page 结构 自身 的 clean, 另外 一 个 就 是 该 page 对 应 的 页 表 项 的 clean, 这 个 clean 
包含 对 这 个 页 表 项 写 保护 L_ PTE_RDONLY 的 重新 置 位 。 这样 对 于 map 到 文件 的 内 存在 其 
下 次 被 修改 后 能 够 产生 写 异常 ， 以 便 内 核能 够 监控 脏 页 的 产生 。 

/* 在 文件 系统 写 回 一 个 page 之后， 调用 该 函数 clean 该 page。 事 实 上 在 虚拟 文件 系统 层 将 脏 写 
回 时 对 于 每 个 page 也 需要 调用 该 函数 */ 
int clear page dirty for io(struct page *page) 

{ 


struct address space *mapping = page mapping (page); 


if (mapping && mapping cap account dirty(mapping)) { 
// 先 做 page 结构 本 身 的 clean， 再 进一步 clean 对 应 pte 
if (page mkclean (page)) 
set page dirty(page); 
} 
return TestClearPageDirty (page); 
} 


//page MMU 映射 方面 的 clean 处 理 
int page mkclean(struct page *page) 


{ 
int ret = 0; 
// 若 该 page 会 映射 到 应 用 的 虚拟 内 存 
if (page mapped (page)) { 
struct address_space *mapping = page mapping (page); 
if (mapping) { 
// 进 一 步 clean 其 pte 
ret = page mkclean file(mapping, page); 


. 


/* 一 个 page 可 能 被 映射 到 多 个 应 用 中 ， 从 反 向 映射 链表 中 依次 找 出 虚拟 内 存 空间 ， 并 清除 其 对 应 
pte*/ 

static int page mkclean file(struct address space *mapping, struct page 

*page) 

{ 
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// 依 次 遍历 映射 该 page 的 反 向 映射 链表 
vma prio tree _ foreach (vma，&iter，&mapping->i mmap, pgoff, pgoff) { 
/* 只 有 VM_SHARED 才 需 要 进行 文件 操作 ， 才 有 做 clean 的 必要 */ 
if (vma->vm flags & VM SHARED) { 
unsigned long address = vma address (page, vma); 
if (address == -EFAULT) 
continue; 
// 在 一 个 虚拟 地 址 空间 做 pte 的 clean 


ret += page mkclean one(page, vma, address); 


// 一 个 pte 的 clean 操作 ， 所 谓 clean， 重 要 的 是 设置 其 只 读 属性 


static int page mkclean one (struct page *page, struct vm area struct *vma, 


unsigned long address) 


// 找 出 pte 


pte = page_ check address (page, mm, address, &ptl, 1); 
if (!pte) 
goto out; 
//pte 为 脏 或 者 pte 没有 置 位 ， 只 读 属性 
if (pte dirty(*pte) || pte write (*pte)) { 


pte t entry; 


// 保 留 原先 的 pte 内容 后 把 该 pte 清 0 

entry = ptep clear flush notify(vma, address, pte); 
// 在 原先 的 pte 内 容 上 置 位 L_PTE_RDONLY 

entry = pte wrprotect (entry); 

// 清 除 原先 的 pte 内 容 上 的 工 PTE_DIRTY 标志 

entry = pte mkclean (entry); 

// 将 处 理 好 的 pte 写 进 页 表 

set_ pte at(mm, address, pte, entry); 

ret = 1; 


6.2.3 ”及 页 的 监控 


在 VM_WRITE|VM_SHARED 属性 的 page 被 clean 之 后 ， 其 pte 为 只 读 属性 ， 若 再 次 
发 生 该 page 的 写 则 产生 新 的 写 异常 ， 走 以 下 路 径 : 
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/* 
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只 考虑 该 函数 处 理 clean 后 且 属 性 为 VM_ WRITE1VM SHARED 的 page 再 次 被 写 访问 


*/ 


static int do wp page(struct mm struct *mm, struct vm area struct *vma, 


unsigned long address, pte t *page table, pmd t *pmd, 


spinlock t *ptl, pte t orig pte) 


releases (pt1) 


// 找 出 该 page 


old page = vm normal page(vma, address, orig pte); 


if (PageAnon(old page) && !PageKsm(old page)) { 


// 匿 名 页 的 情况 不 在 这 里 讨论 ， 参 见 上 文 


} else if (unlikely((vma->vm flags & (VM WRITE|IVM SHARED)) == 


reuse: 


(VM WRITEIVM SHARED))) { 

/*int (*page mkwrite) (…) ;主要 作用 是 等 待 该 页 的 writeback 完成 ， 若 该 页 处 于 
writeback 状态 要 等 待 其 完成 ， 才 能 再 对 其 写 操作 ， 尽 管内 存 操作 仅仅 是 覆盖 原先 
的 内 容 ， 但 是 对 于 文件 系统 要 满足 其 数据 一 致 性 的 保护 机 制 ， 所 以 这 里 需要 交 给 具体 
的 文件 系统 来 做 */ 


if (vma->vm ops && vma->vm ops->page mkwrite) { 


// 由 具体 的 文件 系统 来 做 两 者 的 同步 


tmp = vma->vm ops->page mkwrite(vma, &vmf); 


// 做 下 标志 ， 该 page 要 使 能 写 权 限 
page mkwrite = 1; 
} 
dirty page = old page; 
get _ page (dirty page); 


// 该 页 新 被 访问 ，young 之 

entry = pte mkyoung (orig pte); 

// 使 能 写 

entry = maybe mkwrite (pte mkdirty(entry), vma); 

// 设 置 pte 

if (ptep set access flags (vma, address, page table, entry,1)) 


update mmu cache (vma, address, page table); 


// 如 果 具 体 的 文件 系统 没有 提供 page_mkwrite 内 核 就 需要 自己 做 同步 了 
if (!page mkwrite) { 

// 等 待 该 页 的 writeback 

wait on page _ locked (qirty page) 
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/* 将 该 页 置 脏 ， 并 启动 写 回 机 制 ， 写 回 机 制 的 启动 不 能 太 频 繁 ， 也 不 能 太 稀少 */ 
set page dirty balance(dirty page, page mkwrite); 
} 
put page (dirty page); 
// 写 发 生 标志 
if (page mkwrite) { 
struct address space *mapping = dirty page->mapping; 
/* 将 该 页 置 脏 ， 为 了 支持 不 同 的 架构 处 理 器 ， 不 同 的 文件 系统 ， 内 核 有 些 地 方 不 得 
已 有 些 重复 操作 ， 但 这 一 般 都 是 内 存 操作 ， 不 会 损失 性 能 */ 
set page dirty(dirty page); 


if (mapping) { 
/* 检 查 是 否 到 了 写 回 时 机 */ 
balance dirty pages ratelimited (mapping); 


} 


/* 下 一 步 还 要 将 该 页 的 pte 置 脏 位 工 PTE_DIRTY， 这 个 工作 在 上 一 级 函数 完成 。 参 见 
下 文 */ 


return ret; 


63 全 景 图 


本 节 分 析 缺 页 请 页 的 框架 函数 ， 该 函数 由 数据 、 指 令 转换 异常 而 来 ， 那 里 是 虚拟 内 存 
触发 时 机 的 源泉 。 对 于 Android 操作 系统 来 说 ， 这 里 才 是 内 存 管 理 真正 开始 的 地 方 。 


// 页 表 项 异常 处 理 函数 

int handle pte fault(struct mm struct *mm, 
struct vm area struct *vma, unsigned long address, 
pte t *pte, pmd t *pmd, unsigned int flags) 


pte t entry; 
spinlock t *ptl; 


entry = ptes 
/*pte 状态 表明 了 其 对 应 页 面 所 处 的 状态 */ 
if (!pte present (entry)) { 
if (pte none(lentry)) { 
/*pte 为 0， 表明 有 如 下 可 能 
File backed 或 者 匿名 页 第 一 次 被 访问 
File backed 页 被 shrink page 1ist 释放 掉 之 后 ,又 一 次 被 访问 。 参见 shrink page list 
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的 分 析 ， 每 次 释放 掉 一 个 File backed 页， 其 PTE 都 被 置 为 0。 


*/ 


*/ 


} 


if (vma->vm ops) { 
/*vma->vm ops 是 在 做 内 存 的 file mmap 复制 的 ， 对 于 File backed 页 ， 该 
条 件 成 立 */ 
if (likely (vma->vm ops->fault) ) 
return do linear fault (mm, vma, address, 
pte, pmd, flags, entry); 
} 
// 第 一 次 访问 匿名 页 
return do anonymous page (mm, vma, address, 
pte, pmd, flags); 

} 

/*L _PTE _ FILE 非 线 性 的 file mmap， 在 Android 系统 里 没有 发 现 这 种 用 法 。 这 里 是 
Linux 内 核 与 系统 关系 非常 好 的 实例 。 博 大 精深 的 Linux 内 核 支持 多 种 内 存 映射 、 
文件 读 写 、 进 程 调度 等 方面 的 机 制 ， 但 是 操作 系统 往往 不 会 使 用 其 全 部 机 制 。 一 个 好 
的 操作 系统 ， 往 往 只 是 用 到 了 其 中 一 些 适 合 自己 上 层 建筑 的 机 制 。 因 为 对 于 操作 系统 
而 言 ， 一 个 良好 的 上 层 建筑 是 不 可 能 把 所 有 的 Linux 内 核 机 制 都 利用 到 。 读 者 也 许 会 
反问 ，ubuntu 之 类 的 系统 不 是 暴露 了 全 部 的 Linux 内 核 机 制 吗 ? 但 是 笔者 认为 ， 
ubuntu 之 类 的 系统 ,只 是 Linux 内 核 的 外 延 , 并 不 是 一 个 完整 的 操作 系统 ,而 Linux 
之 所 以 在 服务 器 上 大 行 其 道 ， 是 因为 部 分 redhat 、ubuntu 所 欠缺 的 操作 系统 功能 
被 商业 公司 的 中 间 件 实现 了 。 而 且 ubuntu redhat 暴露 的 内 核 机 制 有 多 少 会 被 这 些 
承载 操作 系统 机 制 的 中 间 件 使 用 到 ? 再 之 ， 又 有 读者 可 能 会 反问 : ubuntu 上 面 不 是 
集成 了 GTK、QT、 等 一 堆 组 件 ， 这 些 不 是 构成 操作 系统 的 要 素 吗 ? 诚然 ，ubuntu 
上 集成 了 一 堆 优秀 的 开源 组 件 ， 但 是 其 并 不 能 构成 操作 系统 。 尽 管 ubuntu 其 上 不 乏 
大 量 优秀 的 开源 组 件 ， 但 是 它们 只 是 “ 堆 ” 在 那里 ， 没 有 形成 一 个 良好 的 架构 ， 其 之 
间 没 有 有 机 的 联系 ! 且 功 能 往往 重复 、 互 相 之 间 没 有 留 有 合适 的 接口 ， 没 有 良好 的 统 

-管理 机 制 。 这 是 开源 Linux 界 的 最 大 问题 ， 各 种 项 目 各 自 为 战 ， 没 有 合力 ， 无 法 形 
成 良好 的 操作 系统 的 上 层 建筑 。 为 什么 这 种 “ 攒 ”出 来 的 Linux 系统 为 什么 一 直 在 桌 
面 、 手 机 上 一 败 再 败 ， 因 为 需要 的 是 操作 系统 ， 提 供 的 却 只 是 内 核 和 一 堆 不 相干 的 组 件 


if (pte_file (entry) ) 
return do nonlinear fault (mm, vma, address, 
pte, pmd, flags, entry); 
// 匿 名 页 ， 被 SWAP 到 SWAP 分 区 或 文件 中 了 
return do_swap page (mm, vma, address, 
pte, pmd, flags, entry); 


ptl = pte lockptr (mm, pmd); 
spin lock(pt1); 
if (unlikely(!pte same(*pte, entry))) 


goto unlock; 


/* 写 异常 。 走 到 这 里 的 情况 不 是 因为 时 指针 的 写 ， 郊 种 情况 在 ”do_page_fault 里 就 被 截 
获 了 。 这 里 的 情况 是 COW 的 处 理 和 脏 页 的 监控 */ 
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if (flags & FAULT FLAG WRITE) { 

if (!pte write(entry)) 

return do wp page (mm, vma, address, 
pte, pmd, ptl, entry); 
/* 被 shrink 掉 的 VM_SHARED 的 非 匿 名 内 存 走 到 这 里 ， 内 核 在 这 里 监控 脏 页 的 产生 */ 
entry = pte mkdirty (entry); 

} 
// 该 页 新 被 访问 ， 置 位 LPTE_YOUNG 
entry = pte mkyoung (entry); 
// 设 置 pte 
if (ptep set access flags (vma, address, pte, entry, flags & FAULT FLAG_ 
WRITE)) { 

update mmu cache(vma, address, pte); 
} else { 
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在 Linux 体系 下 没有 哪个 驱动 子 系统 的 地 位 像 Block 那么 重要 。 

整个 数据 流 的 最 终 搬运 工作 是 由 Block 负责 的 。 而 存储 介质 的 访问 又 是 系统 存储 中 最 
慢 的 地 方 。Block 的 性 能 决定 了 整个 系统 性 能 表现 。 

对 于 不 是 基于 块 设备 文件 系统 ， 文 件 系统 基于 一 个 特殊 的 驱动 子 系统 处 理 存 储 介质 ， 
如 jffs2 直接 架 在 MTD 设备 上 。 但 是 大 部 分 的 文件 系统 是 基于 块 设备 的 ， 服 务 器 、PC 使 
用 SCSI、SSD 自 不 用 说 。 

在 移动 领域 随 着 emmc 的 兴起 ， 使 其 成 为 根 目录 文件 系统 已 是 不 二 选择 ， 而 emmc 本 
身 就 是 一 种 标准 的 Block 类 型 设备 ， 这 使 得 智能 手机 根 目录 文件 系统 自然 选择 ext4 了 。 

而 对 于 非 标准 块 设备 ， 还 可 以 通过 驱动 来 模拟 块 设备 ， 比 如 nand 的 设备 ，Linux 提供 
了 一 个 mtkblock block 驱动 来 模拟 块 设备 ，yaffs2 就 基于 这 种 设备 接 驶 在 Block 上 。 


7.1 Bdev 文件 系统 


Bdev 文件 系统 是 一 个 特殊 的 文件 系统 , 它 将 块 设备 文件 抽象 为 一 个 普通 的 inode 节点 ， 
这 样 就 可 以 使 用 普通 文件 处 理 框架 来 处 理 块 设备 ， 这 样 Bdev 文件 系统 的 节点 就 与 系统 中 
块 设备 对 应 起 来 。 

其 用 途 主要 在 两 方面 : 一 是 直接 使 用 原始 块 设备 ， 就 需要 通过 Bdev 文件 系统 处 理 ， 
Bdev 为 其 提供 了 像 处 理 普通 文件 的 struct address_space_operations def blk_aops; 另 一 方面 
是 被 文件 系统 本 身 使 用 , 文件 系统 在 处 理 自己 元 数据 时 , 实际 上 是 直接 对 块 设备 进行 处 理 ， 
这 时 也 通过 Bdev 文件 系统 处 理 来 处 理 。 

本 节 描 述 Bdev 基本 结构 ， 但 是 对 于 bdev 文件 系统 的 使 用 才 是 其 工作 机 制 的 关键 ， 贯 
穿 本 章 整个 章节 ， 参 见 下 文 。 

Bdev 文件 系统 的 描述 如 下 : 


static struct file system type bd type = { 
.name = "bdev", 
/* 挂 载 时 将 执行 该 函数 */ 
.mount = bd mount, 
-kill sb = kill anon super, 


}; 
bdev 文件 系统 的 挂 载 如 下 : 


void _init bdev cache init(void) 


{ 
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// 注 册 bdev 文件 系统 
err = register filesystem(&bd type); 
if (err) 
panic("Cannot register bdev pseudo-fs"); 
// 挂 载 bdev 文件 系统 


bd mnt = kern mount (gbd type); 


/*bdev 是 仅 存在 于 内 核 的 文件 系统 ， 适 用 伪 文 件 系统 挂 载 例 程 */ 


static struct dentry *bd mount (struct file system type *fs_type， 
int flags, const char *dev name, void *data) 


/* 伪 文件 系统 挂 载 : 分 配 超级 块 、 分 配 根 目录 节点 */ 


return mount pseudol(fs type, "bdev:", &bdev sops, NULL, 0x62646576); 


. 
/*bdev 超级 块 操作 函数 表 */ 


static const struct super operations bdev sops = { 
.statfs = simple statfs, 


// 分 配 新 节点 


-alloc inode = bdev alloc inode, 


}; 
bdev 文件 系统 的 节点 定义 如 下 : 


struct bdev inode { 
struct block device bdev; 
struct inode vfs inode; 


}; 


可 见 bdev inode 是 与 struct block_device bdev; 紧 密 联 系 在 一 起 的 ， 而 bdev 文件 系统 的 
inode 分 配 函 数 每 次 也 是 连同 struct block_device bdev: 一 起 分 配 bdev 的 inode 节点 。 


static struct inode *bdev alloc inode(struct super block *sb) 


{ 
/* bdev_cachep 的 单元 大 小 就 是 sizeof struct bdev inode */ 
struct bdev inode *ei = kmem cache alloc(bdev cachep, GFP_ KERNEL); 
if (+ei) 
return NULL; 
/* 以 struct inode 的 形式 返回 结果 */ 
return &ei->vfs inode; 


} 
为 设备 分 配 bdev 文件 系统 的 节点 如 下 : 


struct block device *bdget (dev_t dev) 
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struct block device *bdev; 
struct inode *inode; 
// 参 加 上 文 inode 的 创建 ， 这 里 调用 到 bdev 文件 系统 的 inode 分 配 函 数 
inode = iget5 locked(blockdev superblock, hash(dev), 
bdev test, bdev set, &dev); 


if (!inode) 
return NULL; 
// BDEV_I 返回 结构 struct bdev_inode 的 起 始 地 址 
bdev = &BDEV I (inode)->bdev; 
// 初 始 化 struct block_device 结构 和 bdev 里 的 struct inode 结构 
if (inode->i state & I NEW) { 
bdev->bd contains = NULL; 
// bd_inode 指向 bdev 的 inode 
bdev->bd inode = inode; 
bdev->bd block size = (1 << inode->i blkbits); 


inode->i bdev = bdev; 
// 设 置 bdev inode 的 i_data 默认 操作 
inode->i data.a ops = &def blk aops; 
mapping set gfp mask(&inode->i data, GFP USER); 
inode->i data.backing dev info = &default backing dev info; 
spin lock(&bdev_ lock); 
// 挂 入 all_bdevs 列表 
list add(gbdev->bd list, &all bdevs); 
spin unlock (gbdev lock); 
unlock new inode (inode); 
} 


return bdev; 


7.2 块 设备 基础 结构 


在 分 析 块 设备 驱动 之 前 ， 首 先 熟悉 一 下 块 设备 的 基本 数据 结构 。 


1. struct gendisk 
内 核 通过 块 设备 描述 结构 struct gendisk 来 描述 整 块 块 设备 ， 代 码 如 下 : 


struct gendisk { 


int major; /* major number of driver */ 


int first minor; 


} 
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// 指 示 设 备 可 以 容纳 的 分 区 数目 ， 如 果 ==1 表示 该 设备 不 能 被 分 区 

int minors; 

/*struct disk part 包含 着 该 块 设备 的 分 区 数组 ， 数 组 中 每 一 项 指向 一 个 分 区 。 而 该 分 区 
数组 的 第 0 项 比较 特殊 ， 它 指向 struct gendisk 的 成 员 变 量 struct hd struct 
part0;， 代 表 块 设备 本 身 ， 当 块 设备 没有 分 区 时 ， 分 区 数组 只 有 这 个 唯一 的 一 项 */ 

struct disk part tbl _rcu *part tbl; 

struct hd struct part07 

// 块 设备 读 写 的 请 求 队列 


struct request queue *queue; 


2. struct hd_struct 


struct hd_struct 描述 块 设备 的 其 中 一 个 分 区 。 


struct hd struct { 
// 起 始 扇 区 


sector t start sect; 


// 该 分 区 的 大 小 


Sector t nr sects; 


// 分 区 号 


}; 


int policy, partno; 


3. struct request_queue 


struct request_queue 是 块 设备 活动 的 中 枢 ， 记 录 了 块 设备 的 操作 队列 、 电 梯 算 法 、 请 
求 操作 触发 函数 等 一 系列 关键 信息 。 


struct request queue { 


struct list head queue head; 
// 上 一 次 合并 的 操作 
struct request *last merge; 


// 使 用 的 电梯 算法 


struct elevator queue *elevator; 


4. struct backing_dev_info 与 struct bdi_writeback 


struct backing_dev_info 用 来 描述 一 个 设备 ， 包 括 块 设 备 。 该 结构 是 主要 用 于 内 核 回 写 


机 制 |: 
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struct backing dev info { 
struct bdi writeback wb; 


} 


“struct bdi_writeback” 是 回 写 控制 结构 ， 其 工作 原理 如 下 


struct bdi writeback { 
// 回 写 deamon 
struct task struct *task; 
// 回 写 时 钟 


struct timer list wakeup timer; 


}; 


struct bdi_writeback 初始 化 时 要 为 其 设置 定时 回 写 时 钟 struct timer list wakeup_timer;， 
该 时 钟 控制 定时 回 写 机 制 的 周期 性 触发 ， 参 见 回 写 部 分 。 该 时 钟 的 触发 函数 为 


wakeup_timer fn: 


static void wakeup timer fn(unsigned long data) 
{ 


struct backing dev info *bdi = (struct backing dev info *)data; 


spin lock bh(gbdi->wb_ lock); 
if (bdi->wb.task) { 
// 如 果 有 定制 的 回 写 线程 ， 叫 醒 之 
wake up_process (bdi->wb.task) 
} else { 
// 没 有 定制 回 写 线程 ， 使 用 内 核 默 认 的 回 写 线程 
wake up_process (default backing dev info.wb.task); 
} 
spin unlock bh(&bdi->wb lock); 


7.3” 块 设备 的 创建 与 注册 


整 块 块 设备 的 注册 是 由 块 设 备 驱动 发 起 的 ， 首 先 块 设 备 驱动 要 为 其 准备 struct 
block_device_operations *fops: 和 struct request_queue *queue; 结 构 。 然 后 块 设备 驱动 要 调 
struct gendisk *alloc_disk(int minors) 来 为 整 块 块 设备 创建 其 描述 结构 struct gendisk 并 注册 
该 整 块 块 设备 。 

// 块 设备 注册 函数 

void add disk(struct gendisk *disk) 
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struct backing dev info *bdi; 
dev t devt; 


int retval; 


disk->flags |= GENHD FL UP; 
//part0 代表 的 是 整 块 块 设备 ， 分 配 其 设备 号 
retval = blk alloc devt (gdisk->part0, &devt); 
if (retval) { 
WARN_ON (1); 
return; 


} 
//part0 的 struct device  _dev 代表 了 整 块 块 设备 
disk to dev(disk)->devt = devt; 


//disk 的 major 为 主 设备 号 ，first_minor 为 第 一 个 分 区 的 minor 设备 号 
disk->major = MAJOR (devt); 
disk->first minor = MINOR (devt); 


/* Register BDI before referencing it from bdev */ 

bdi = &disk->queue->backing dev_ info; 

bdi register dev(bdi, disk devt (disk)); 

// 向 bdev_map 注册 该 整 块 块 设备 的 分 区 范围 

blk register region(disk devt (disk), disk->minors, NULL, 
exact match, exact lock, disk); 

register disk(disk); 

blk register queue (disk); 


/* 整 块 块 设备 的 注册 ， 这 里 面 最 关键 的 一 个 动作 是 导致 该 整 块 块 设备 分 区 表 的 读 取 与 分 区 结构 的 
创建 */ 
void register disk(struct gendisk *disk) 


{ 


struct device *ddev = disk to devl(disk); 


/* 如 果 不 支 持 分 区 ， 返 回 */ 
if (!disk partitionable(disk)) 


goto exit; 


/* 检查 该 设备 是 否 存 在 ， 如 果 该 设备 存在 必 有 容量 值 */ 
if (!get capacity(disk)) 


goto exit; 
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/*part0 的 struct block device， 就 是 该 整 块 块 设备 本 身 。 这 里 将 导致 bdev 文件 系统 
为 该 整 块 块 设备 即 part0 创建 节点 */ 
bdev = bdget disk(disk, 0); 
if (!bdev) 
goto exit; 
//bd invalidated 置 1， 将 导致 分 区 表 的 扫描 
bdev->bd invalidated = 1; 
/* 导 致 static int _ blkqev_get (…) 的 调用 ， 见 下 文 */ 
err = blkdev get (bdev, FMODE READ, NULL); 


/*void register disk(struct gendisk *disk) 导致 该 函数 的 调用 ， 该 函数 在 不 同 的 调用 
时 刻 有 着 不 同 的 路 径 */ 

static int _ blkdev get(struct block device *bdev, fmode t mode, int 

for part) 

{ 


struct gendisk *disk; 


// 通 过 设备 号 找到 对 应 的 struct gendisk 结构 
disk = get gendisk (bdev->bd dev, &partno); 
// 在 整 块 块 设备 注册 时 bdev->bd_openers 不 存在 ， 因 为 这 时 没有 人 动 过 它 
if (!bdev->bd openers) { 

bdev->bd disk = disk; 

bdev->bd contains = bdev; 

// 对 于 整 块 块 设备 partno 为 0 

if (!partno) { 

struct backing dev info *bdi; 


ret = -ENXIO; 
//part0 的 struct hqd struct 
bdev->bd part = disk get part (disk, partno); 
if (!bdev->bd part) 
goto out clear; 


ret = 0; 
// 如 果 整 块 块 设备 有 打开 函数 ， 调 用 之 ， 这 取决 具体 的 驱动 实现 
if (disk->fops->open) { 

ret = disk->fops->open (bdev, mode); 


} 
// 如 果 没 有 人 碰 过 这 个 块 设备 ， 要 检查 其 struct backing dev_ info 
if (!ret && !bdev->bd_openers) { 

bd set sizel(bdev, (loff t)get capacity(disk)<<9); 
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bdi = blk get backing dev info (bdev); 

/* 如 果 了 驱动 层面 没有 提供 struct backing_dev_info， 则 使 用 默认 的 
default backing_ dev_info 作为 其 bdqi, 对 于 emmc 这 种 情况 不 存在 ， 
emmc 驱动 会 提供 自己 的 struct backing dev info*/ 

if (bdi == NULL) 

bdi = &default backing dev info; 
bdev inode switch bdi (bdev->bd inode, bdi); 


/* 
bdev->bd invalidated 为 1， 表示 还 没 进行 分 区 表 的 扫描 ， 下 一 步 要 扫描 分 
区 表 
ef 
if (bdev->bd invalidated && (!ret || ret == -ENOMEDIUM) ) 
rescan partitions(disk, bdev); 
if (ret) 
goto out clear; 
} else { 
// 如 果 打开 的 分 区 设备 
struct block device *whole; 
// 从 bdev 文件 系统 找 出 整 块 块 设备 的 struct block_device 
whole = bdget disk(disk, 0); 
ret = -ENOMEM; 
// 如 果 找 不 到 对 应 的 整 块 块 设备 ， 那 么 也 没有 必要 下 一 步 了 
if (!whole) 
goto out clear; 
/#* 递 归 ， 去 看 一 下 整 块 块 设备 是 否 已 经 被 打开 、 扫 描 过 ， 如 果 没 有 ， 先 要 进行 整 块 
块 设备 的 分 区 扫描 */ 
ret = _ blkdev get (whole, mode, 1); 
if (ret) 
goto out clear; 
// 分 区 块 设备 的 归属 是 整 块 块 设备 
bdev->bd_ contains = whole; 
/* 找 出 分 区 块 设备 对 应 的 bdev 文件 系统 的 inode， 并 将 其 inode->i_data. 
backing_dev_info 指向 整 块 块 设备 的 bdi*/ 
bdev_inode switch bdi (bdev->bd inode, 
whole->bd inode->i data.backing dev info); 
// 分 区 块 设备 的 struct hq _struct 
bdev->bd part = disk get part(disk, partno); 


// 设 置 分 区 容量 
bd set size (bdev, (loff t)bdev->bd part->nr sects << 9); 
} 


} else { 
/* e2fsck 的 时 候 走 到 这 里 ， bd_openers 有 值 ， 且 是 打开 的 整 块 块 设备 ， 不 过 这 个 时 
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候 bdev->bqd invalidated 已 经 被 清 0， 所 以 不 会 导致 再 次 扫描 分 区 表 */ 
if (bdev->bd contains == bdev) { 
ret = 0; 
if (bdev->bd disk->fops->open) 
ret = bdev->bd disk->fops->open (bdev, mode); 
/* the same as first opener case, read comment there */ 
if (bdev->bd invalidated && (!ret || ret == -ENOMEDIUM) ) 
rescan partitions (bdev->bd disk, bdev); 
EE {ret} 
goto out unlock bdev; 
} 
/* only one opener holds refs to the module and disk */ 
put disk(disk); 
module put (owner); 
} 
/1 成 功 被 打开 


bdev->bd_openerst++; 


7.4 分 区 检测 生成 


Linux 内 核 支 持 多 种 格式 分 区 形式 ， 针 对 每 种 分 区 格式 ， 内 核 在 fs/partitions/check.c 里 
提供 了 检测 函数 : 
/* 分 区 格式 检测 函数 列表 。 每 种 分 区 都 有 自己 的 检测 函数 ， 通 过 CONFIG 来 激活 */ 


static int (*check part[]) (struct parsed partitions *) = { 


#ifdef CONFIG ACORN PARTITION ICS 
adfspart check ICs, 
#endif 


// 这 是 常用 的 分 区 格式 

#ifdef CONFIG MSDOS _ PARTITION 
msdos_partition, 

#endif 

} 


/* 分 区 监测 与 生成 ， 设 备注 册 时 会 触发 该 函数 */ 
int rescan partitions(struct gendisk *disk, struct block device *bdev) 


{ 


rescan: 
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// 调 用 分 区 检测 函数 ，state 返回 的 是 监测 到 的 分 区 数组 
if (!get capacity(disk) || !(state = check partition(disk, bdev))) 


return 0; 


/* 针对 检测 到 每 一 分 区 操作 */ 
for (p= 1; p< state->limit; p++) { 
sector t size, from; 
struct partition meta info *info = NULL; 


// 记 录 分 区 大 小 


size = state->parts[p] .size; 


// 记 录 分 区 起 点 

from = state->parts[p] .from; 

/* 向 系统 注册 这 个 分 区 对 应 的 块 设备 。 该 分 区 获得 在 内 核 中 的 身份 struct hd_struct*/ 
part = add partition(disk, p, from, size, 


state->parts[p] .flags, 
&state->parts[p] .info); 


7.5 块 设备 的 打开 


可 以 不 考虑 块 设备 作为 raw 设备 被 应 用 进程 用 open 调用 的 情况 , 这 种 方式 使 用 块 设 备 
在 Android 及 大 多 数 PC 系统 都 是 不 存在 的 ， 仅 考虑 在 加 载 基于 块 设备 的 文件 系统 时 打开 
块 设备 的 情况 。 

首先 ， 这 种 方式 打开 的 块 设备 有 两 个 struct inode 结构 : 

(1) struct inode 对 应 是 该 设备 的 设备 文件 ， 该 struct inode 位 于 这 个 设备 文件 所 在 文件 
系统 ， 这 是 一 个 普通 的 struct inode。 

(2) struct inode 就 是 位 于 bdev 文件 系统 ，bdev 文件 系统 通过 这 个 struct inode 操作 该 
设备 。 

Block 设备 的 lookup 过 程 很 好 地 说 明了 这 个 问题 ， 代 码 如 下 : 

struct block device *]lookup bdev(const char *pathname) 


{ 


/pathname 为 块 设备 文件 在 当前 文件 系统 里 的 位 置 ， 在 当前 文件 系统 查找 它 ， 查 找 的 结果 放 
在 path 里 */ 
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error = kern path (pathname，LOOKUP FOLLOW，&path) ; 
if (error) 
return ERR PTR(error); 
/* 从 查找 结果 里 取出 设备 文件 在 当前 文件 系统 里 的 inode*/ 
inode = path.dentry->d inode; 
error = -ENOTBLK; 
/* 如 果 不 是 块 设备 ， 说 明 出 错 了 */ 
if (!S ISBLK (inode->i mode)) 
goto fail; 
error = -EACCES; 
/* path.mnt 指向 当前 文件 系统 ，MNT_NODEV 表示 不 允许 访问 当前 文件 系统 的 特殊 文件 ， 
如 果 这 个 条 件 成 立 ， 这 个 设备 文件 就 不 能 打开 */ 
if (Path.mnt->mnt flags & MNT_NODEV) 
goto fail; 
error = -ENOMEM; 
/* 将 当前 文件 系统 的 inode 与 struct block_device 联系 起 来 */ 


bdev = bd _acquire (inode); 


static struct block device *bd acquire(struct inode *inode) 


‘ 


struct block device *bdev; 
/* bdev_lock 是 保护 块 设备 的 锁 */ 
spin lock(&bdev_ lock) 
/*inode 结构 的 struct block device *i bdev; 指 针 */ 
bdev = inode->i bdev; 
/* 如 果 指 针 不 空 表示 已 与 bdev 文件 系统 关联 上 */ 
if (bdev) { 
/* 将 bdev inode 引用 计数 加 一 ， 表 示 又 多 了 个 使 用 者 */ 
ihold (bdev->bd inode); 
spin unlock (gbdev lock); 
return bdev; 
} 
spin unlock (gbdev lock); 
/* 指 针 不 空 表示 bdev 文件 系统 对 应 的 inode 还 没 创建 ， 调 用 bdget 创建 bdev 文件 系统 的 
inode*/ 
bdev = bdget (inode->i rdev); 
/*bdev 为 bdev 文件 系统 的 inode 指针 ， 参 见 bdev 文件 系统 inode 定义 */ 
if (bdev) { 
spin lock(&bdev lock); 
/* 建 立 其 两 个 inode 的 联系 */ 


if (!inode->i bdev) { 


ihold (bdev->bd inode); 
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inode->i bdev = bdev; 
/* i mapping 指向 bdev 文件 系统 inode 的 i mapping ， 说明 如 果 有 open 
write， 该 inode 有 时 也 是 通过 bdev 文件 系统 inode 来 处 理 */ 
inode->i mapping = bdev->bd inode->i mapping; 
/* 一 个 设备 可 能 有 多 个 设备 文件 ， 将 这 些 设备 文件 串 起 来 ， 挂 在 自己 的 bq_inodes 链表 上 */ 
list add (ginode->i devices, gbdev->bd inodes); 
} 
spin unlock(&bdev lock); 
} 


return bdev; 


7.6” 块 设备 驱动 的 层次 结构 


块 设备 驱动 也 分 为 多 个 层次 ， 最 下 面 的 是 芯片 操作 相关 的 驱动 ， 如 某 个 型 号 的 IDE、 
SCSI、MMC 控制 芯片 。 再 往 上 是 协议 相关 的 驱动 子 系统 ， 如 IDE 类 驱动 、SCSI 类 驱动 、 
MMSC 类 驱动 。 再 往 上 就 是 抽象 的 块 设备 驱动 。 若 讨论 具体 的 驱动 子 系统 实现 还 可 以 再 细 
分 ， 但 是 针对 Linux 内 核 架 构 的 讨论 ， 分 成 三 个 层次 足够 了 。 本 节 仅 讨论 抽象 的 块 设备 驱 
动 。 而 块 设备 驱动 在 内 核 架 构 的 地 位 如 此 重要 ， 为 了 能 够 从 底 到 上 、 员 通 的 理解 Android 
系统 工作 机 理 ， 本 书 另 辟 一 章 分 析 在 手机 、 垦 入 式 领 域 大 量 使 用 的 EMMC、SD 卡 块 设备 
驱动 。 

抽象 的 块 设备 驱动 位 于 文件 系统 的 下 侧 和 具体 存储 设备 驱动 的 上 侧 。 接 受 文件 系统 的 
提交 的 读 写 请 求 ， 并 使 用 自身 的 电梯 算法 加 以 优化 ， 再 将 请 求 下 发 给 存储 设备 驱动 。 

文件 系统 将 文件 块 的 操作 以 struct buffer_head 为 单位 提交 到 block 层 ，block 层 将 其 再 
次 包装 成 struct bio 提交 到 抽象 块 设备 驱动 。 接 着 ， 抽 象 块 设备 驱动 层 找到 对 应 块 设备 抽象 
出 来 的 struct request_queue 结构 并 执行 其 make_request_fn*make _ request fn: 函数 。 而 下 层 
的 块 设备 驱动 的 需要 根据 自己 的 特殊 情况 来 实现 该 函数 。 而 对 于 块 设备 来 说 ， 有 着 很 多 共 
性 ， 所 以 内 核 为 其 提供 了 static int ”make_request(…) 例 程 ， 而 大 多 数 块 设备 子 系 统 都 接受 
了 这 个 默认 例 程 : 


static int make request (struct request queue *q, struct bio *bio) 
{ 
/* 
Plug 机 制 ， 某 个 线程 提交 的 块 设备 操作 有 着 很 强 的 连贯 性 ， 所 以 这 里 首先 检查 该 bio 是 否 能 
和 当前 线程 plug 里 的 bio 合并 
*/ 
if (attempt plug merge(current, q, bio)) 


goto out; 


spin lock irq(q->queue lock); 
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/* 检 查 该 bio 是 否 可 以 和 该 设备 待 处 理 队列 里 的 其 他 bio 合并 ，elv merge 指出 是 向 前 合 
并 还 是 向 后 合并 */ 

el ret = elv merge(lq, é&req, bio); 

if (el ret == ELEVATOR BACK MERGE) { 


// 后 向 合并 

if (bio attempt back mergel(q, req, bio)) { 
让 (!'attempt back merge(gq, req)) 

elv merged request(q, req, el ret); 

// 后 向 合并 成 功 ， 完 成 了 该 bio 的 处 理 
goto out unlock; 

} 

} else if (el ret == ELEVATOR FRONT MERGE) { 


// 前 向 合并 
if (bio attempt front merge(q, req, bio)) { 
if (!attempt front merge(q, req)) 
elv merged request (gq, req, el ret); 
// 前 向 合并 成 功 ， 完 成 了 该 bio 的 处 理 


goto out unlock; 


get rq: 
// 没 有 合并 成 功 走 到 这 里 ， 检 查 该 bio 是 读 还 是 写 
rw flags = bio data dir(bio); 
if (sync) 
rw flags |= REQ SYNC; 


/* 

下 层 的 块 设备 驱动 准备 了 一 个 struct request_queue 数组 ， 用 来 盛 放 抽象 块 设备 驱动 提 
交 来 的 读 写 操作 。 这 里 即 从 struct request_queue 数组 里 找到 一 项 

*/ 

req = get request wait(q, rw flags, bio); 


/* 
把 bio 放 到 struct request queue 里 
*/ 


init request from biol(req, bio); 


// 检 查 plug 机 制 
Plug = current->plug; 
if (plug) { 
/* 一 次 读 写 操作 可 能 会 包含 多 个 bio， 而 这 些 bio 之 间 往 往 存在 连贯 关系 ， 所 以 对 于 一 


次 读 写 ， 内 核 提供 了 plug 机 制 ， 以 便 在 整个 读 写 操作 都 完成 之 后 再 启动 底层 的 实际 
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设备 操作 ， 以 便 进行 bio 之 间 的 merge。 这 里 正 是 一 次 读 写 操作 间 的 “bio” 提 交 */ 


// 将 这 些 bio 串 起 来 ， 待 读 写 操作 完成 再 unplug 这 个 bio 队列 
list add tail(&req->queuelist，&plug->1list) 7 


} else { 
/* 没 有 plug， 说 明 这 个 bio 需要 及 时 提交 到 下 层 驱动 。struct request queue 结 
构 的 request fn proc *request _ fn; 函数 是 下 层 驱 动 实际 工 作 的 入 口 ， 通 常 由 
具体 的 设备 子 系统 来 实现 。 比 如 static void mmc_ request (struct request_ 
queue *q) 是 mmc 子 系统 的 入 口 */ 
_blk run queue (9) 
out_unlock: 


} 


7.7 虚拟 块 设备 


有 些 存 储 介质 的 直接 操作 ， 尽 管 不 具有 块 设备 的 特性 。 但 是 为 了 更 好 地 适 配 到 Linux 
内 核 的 基础 架构 ， 在 驱动 层 做 了 一 层 虚 拟 的 块 设备 层 ， 将 对 实际 设备 的 操作 都 转换 为 基本 
的 块 设备 操作 。 

以 Nand 的 设备 为 例 ， 本 身上 并 不 具备 块 设备 特性 ， 但 是 其 上 的 文件 系统 如 Yaffs2 往 
往 又 需要 使 用 块 设备 特性 来 接 驱 Linux 内 核 基础 架构 。 所 以 Yaffs2 文件 系统 使 用 了 虚拟 的 
Nandblock 设备 。 

/+ 文件 系统 加 载 基本 操作 : 获取 对 块 设备 使 用 权 ， 以 Yaffs2 为 例 分 析 */ 

struct block device *lookup bdev (const char *pathname) 


{ 


/* 查 找 该 设备 文件 ，path.dentry->d_inode 返回 rootfs 里 对 应 于 该 设备 文件 的 ijnode*/ 
error = kern path(pathname, LOOKUP FOLLOW, &path); 


//dev/block/mtdblock0 是 块 设备 。 不 同 于 jffs2 直接 使 用 mtd，yaffs2 把 nand 当成 
mtdblock 来 用 ， 这 样 给 内 核 暴露 出 来 的 是 一 个 标准 的 block device， 其 暴露 在 VES 层面 的 
行为 特性 就 跟 ext3/4 很 相似 了 

wf 

if (!S ISBLK(inode->i mode)) 
goto fail; 
error = -EACCES; 


// 在 bdev 虚拟 文件 系统 里 为 /dev/block/mtdblock0 分 配 一 个 节点 
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bdev = bd acquire (inode); 
} 


而 在 mtdblock 层 ， 其 对 nand 的 操作 被 封装 在 一 个 标准 的 块 设备 中 ， 代 码 如 下 : 


/*mtdblock 的 抽象 函数 在 mtkblock 初始 化 时 被 触发 */ 
int add mtd blktrans dev(struct mtd blktrans dev *new) 
{ 

/*struct gendisk 的 分 配对 应 于 整个 虚拟 mtdblock 设备 */ 

gd = alloc disk(1 << tr->part bits); 


/*struct request _queue 的 分 配 用 来 接 驳 block 层 ， 内 核 所 有 对 nand 的 读 写 操作 都 
被 static void mtqd blktrans_request (…) 转换 成 标准 块 设备 操作 了 */ 


new->rq = blk init _queue (mtd blktrans request, &new->queue lock); 


// 向 内 核 扫 描 并 注册 分 区 设备 
add disk(gd); 


} 


以 上 仅 以 nand 设备 作为 分 析 实 例 , 事实 上 作为 一 种 最 佳 接 驶 VFS 的 机 制 , 基于 Linux 
内 核 系统 使 用 大 量 的 虚拟 块 设备 机 制 。 如 KVM guest 用 的 Virtio_blk， 网 络 块 设备 用 的 
NBD 等 。 
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VFS 是 Linux 内 核 基本 组 成 部 分 。 从 功能 实现 角度 来 说 ， 内 核 只 做 了 两 件 事 情 : 一 是 
“ 攒 ” 除 进 线程 运行 的 机 制 ， 二 是 给 进 线程 提供 一 个 与 外 界 交互 的 窗口 。VFS 就 是 这 个 
窗口 。 

VFS 分 为 以 下 四 层 。 

(1) 第 一 层 是 一 个 抽象 框架 ， 对 应 于 系统 调用 ， 由 Linux 内 核实 现 ， 包 括 文件 的 打开 、 
读 写 。 

(2) VFS 第 二 层 对 应 于 struct file_operations， 有 两 种 选择 : 一 是 提供 特定 文件 系统 ， 
该 文件 系统 的 实现 完全 任意 ， 只 要 满足 内 核 抽 象 的 文件 的 打开 、 读 写 等 操作 即 可 ; 第 二 种 
选择 的 背景 是 ， 内 核 基 于 其 自身 的 回 写 机 制 以 及 文件 的 page cache 机 制 提 供 了 一 套 基本 的 
文件 操作 函数 。 具 体 的 文件 系统 在 该 层 使 用 这 套 函 数 即 可 。 

VFS 第 二 层 是 实现 内 核 深度 裁剪 的 最 佳 位 置 。 从 内 核实 现 的 角度 来 讲 ， 具 体 的 文件 
系统 只 要 满足 基本 的 文件 操作 就 能 挂 载 到 内 核 上 ， 而 不 需要 脏 页 的 回 写 机 制 以 及 文件 的 
page cache 机 制 。 而 对 于 深度 嵌入 式 系统 ， 如 小 型 的 NOMMU 的 系统 ， 其 上 文件 系统 非常 
简单 ， 甚 至 可 有 可 无 。 脏 页 的 回 写 机 制 以 及 文件 的 page cache 机 制 对 其 来 说 是 个 累 歼 。 所 
以 在 这 里 实现 特定 文件 系统 ， 绕 过 VFS 更 深 的 层次 ， 就 可 以 显著 简化 内 核 ， 就 像 一 个 卸 掉 
了 负载 车 厢 的 火车 头 一 样 。 

对 于 Linux 系统 上 的 大 部 分 文件 系统 都 需要 使 用 Linux 优秀 的 page cache、 回 写 等 机 制 ， 
所 以 基本 上 都 会 选择 使 用 Linux 提供 的 例 程 来 实现 。 

(3) VFS 的 第 三 层 对 应 于 struct address_space_operations， 是 针对 文件 系统 的 具体 的 磁 
盘 映 射 、 预 读 、 脏 页 提交 等 操作 更 深 一 步 抽象 的 文件 操作 。 对 于 标准 的 块 设备 的 文件 系统 ， 
内 核 在 这 里 也 提供 像 第 二 层 一 样 ， 提 供 了 基本 的 操作 函数 ， 文 件 系统 的 实现 可 以 选择 使 用 
这 些 内 核 例 程 或 重新 实现 。 而 对 于 一 些 非 标准 的 块 设备 文件 系统 如 jffs2 就 无 法 使 用 内 核 例 
程 ， 必 须 自己 实现 。 

(4) VFS 第 四 层 是 文件 磁盘 布局 的 体现 。 这 里 每 个 文件 系统 都 不 同 ， 只 能 由 具体 的 文 
件 系统 提供 ， 如 int ext4_get_block(…)。 

另外 VFS 还 包括 文件 系统 的 加 载 、 根 目录 的 实现 、 目 录 cache、inode cache 等 方面 的 
内 容 ， 这 些 与 架构 关系 不 大 ， 且 已 经 有 很 多 介绍 资料 ， 本 书 不 再 介绍 。 


81 根 目录 


系统 中 总 有 一 个 根 目 录 ， 本 节 讨论 这 个 根 目录 的 起 源 。 
首先 ， 根 目录 也 是 目录 ， 也 必然 属于 某 个 文件 系统 。 内 核 要 为 根 目录 文件 系统 准备 好 
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基础 架构 。 


void _init mnt_init(void) 
{ee 
// sysfs 文件 系统 的 初始 化 


err = sysfs init(); 


// 初 始 化 根 目录 文件 系统 ， 根 目录 文件 系统 基于 ramfs 架构 
init rootfs(); 
// 生 成 / 


init mount tree(); 


// 根 目录 文件 系统 的 载体 一 一 ramfs 
int _init init rootfs(void) 
{ 
int err; 
//ramfs 的 bdi 
err = bdi init(g&ramfs backing dev info); 


// 注 册 rootfs_fs_type， 其 实际 工作 都 是 基于 ramfs 


err = register filesystem(&rootfs fs type); 


return err; 


} 


// 加 载 根 目录 文件 系统 
static void _init init mount tree(void) 
{ 
//mount roofs， 其 实 就 是 ramfs 
mnt = do_ kern mount ("rootfs", 0, "rootfs", NULL); 


//mount 上 的 fs 的 root 被 当成 整个 系统 的 / 

root.mnt = ns->root; 

root.dentry = ns->root->mnt root; 
// 设 置 到 进程 的 当前 目录 

set fs pwd(current->fs, &root); 
// 设 置 到 进程 的 root 


set fs root(current->fs, g&root); 


} 


在 往 后 生成 init 的 操作 都 是 使 用 CLONE FS 标识 。 如 果 不 重新 使 得 这 个 目录 真正 成 
潮 鸭 党 
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8.1.1 根 目录 文件 系统 一 一 initramfs 


如 果 系 统 使 用 initramfs 机 制 ， 内 核 通过 宏 rootfs_initcall(populate rootfs): 将 initramfs 
初始 化 函数 编译 进 初 始 化 函数 指针 列表 。int _init populate rootfs(void) 函 数 得 以 执行 。 

该 函数 做 如 下 操作 : 

(1) 解压 _initramfs end ---_initramfs start 之 间 的 压缩 文件 。 

(2) 根据 解压 出 的 内 容 执行 如 下 动作 : 


static _ initdata int (*actions[]) (void) = { 
[Start] = do start, 
[Collect] = ducollect, 


[GotHeader] = do header, 
[SkipIt] = do_skip, 
[GotName] = do_name, 
[CopyFile] = do_copy, 
[GotSymlink] = do_symlink, 
[Reset] = do reset, 


}; 

(3) 这 些 操作 实际 上 是 调用 具体 文件 系统 的 操作 函数 、 创 建 目录 或 复制 文件 。 
以 GotName 操作 为 例 ， 代 码 如 下 : 

static int _init do name (void) 


{20 
if (S_ISREG (mode)) {// 常 规 文件 


int openflags = O_WRONLY|O_CREAT; 
// 以 创建 方式 打开 该 文件 


wfd = sys_open(collected, openflags, mode); 
} else if (S_ISDIR (mode)) {// 目 录 


// 创 建 目 录 
sys_mkdir (collected, mode); 
} else if (S_ISBLK (mode) || S_ISCHR (mode) 11 
S_ISFIFO (mode) || S_ISSOCK (mode)) { 
if (maybe link() == 0) { 
/ /创建 设备 节点 


sys_mknod(collected, mode, rdev); 


} 
return 0; 


} 
然而 隐藏 在 这 之 后 一 个 因素 是 ， 这 些 文件 操作 使 用 恰恰 正 是 ramfs 文件 系统 。 在 前 面 
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的 static void _init init mount tree(void) 里 已 经 把 文件 系统 的 架子 都 搭 好 了 ， 这 里 做 的 其 实 
就 是 填充 动作 。 


8.1.2 Android ramdisk.img 


对 于 Android，roofs 就 是 ramdisk.img。Android 使 用 ramfs 来 构架 它 的 最 顶层 的 文件 
系统 。 不同 于 直接 加 载 根 目录 设备 ， 再 找 init 的 做 法 ，Android 这 种 文件 系统 的 构建 方式 给 
了 init 进程 极 大 的 灵活 性 ， 使 其 在 完成 系统 初始 化 过 程 中 自主 加 载 主力 文件 系统 。 作 为 内 
核 与 系统 的 桥梁 ，init 进程 可 以 看 作 内 核 的 延伸 ， 使 其 与 内 核 一 同 加 载 ， 紧 接 其 后 运行 ， 
避免 了 内 核 必须 过 早 的 加 载 根 目 录 设 备 驱动 的 生硬 做 法 。 从 早期 的 ramdisk 演进 到 ramfs， 
在 Android 系统 上 得 到 了 完美 的 体现 。 

(1) 内 核 解 压 initramfs， 生 成 基本 的 最 上 层 目录 结构 。 

(2) Uboot 把 ramdisk.img 甩 到 内 存 的 一 个 地 址 ， 并 通知 内 核 。 

(3) 内 核 启动 到 最 后 ， 找 到 ramdisk.img， 并 把 它 解压 并 生成 一 个 基于 cache 的 文件 系 
统一 一 这 就 是 Android 最 顶层 的 文件 系统 ，init 进程 存放 的 地 方 。 

(4) 内 核 释放 掉 ramdisk.img 所 占 空 间 ( 因 为 ramdisk.img 内 容 已 经 被 取出 构建 rootfs )。 

(5) 内 核 进入 用 户 态 ， 执 行 /init。 


8.1.3 ”传统 根 目 录 文件 系统 加 载 方式 


如 果 没 有 使 用 initramfs，kernel_init 进入 到 void _init prepare_namespace(void); 以 传统 
方式 加 载 根 目录 文件 系统 。 

(1) 找到 root 设备。 

(2) 用 已 注册 的 文件 系统 去 尝试 加 载 该 root 设备 到 目录 /root。 


static int _init do mount root (char *name, char *fs, int flags, void *data) 
{ ”// 挂 到 /root 


int err = sys_ mount (name, "/root", fs, flags, data); 


// 设 置 /root 为 当前 目录 : set_fs_pwd (current->fs, &path); 
sys_chdir("/root"); 


return 0; 


(3) 把 当前 目录 move 到 /, 设置 当前 目录 到 FS 的 root(set_fs_root(current->fs, &path); )。 


8.2 文件 打开 


文件 是 进程 的 窗户 。 
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8.2.1 目录 的 层级 查找 

目录 也 是 文件 ， 只 是 里 面 的 内 容 是 描述 的 文件 系统 结构 。 目 录 的 查找 就 是 在 这 些 目录 
文件 中 找到 需要 的 描述 项 。 

/* 


该 函数 逐 层 解析 文件 路 径 , 并 在 上 层 路 径 分 量 里 的 dcache 或 者 文件 系统 里 , 查找 下 一 层 路 径 分 量 ， 
直到 查找 到 最 终 节点 


static int link path walk(const char *name, struct nameidata *nd) 


{ 


Wh 


// 跳 过 连续 的 / 


while (*name=="'/"') 


Dame 十 十 7 


if (!*name) 


return 0; 


逐 层 查找 */ 
for(;;) { 


unsigned long hash; 
struct qstr thiss 
unsigned int c; 

int type; 


nd->flags |= LOOKUP CONTINUE; 


err = may_lookup (nd); 


if (err) 
break; 
//this 指向 当前 分 量 


this.name = name; 
C=* (const unsigned char *)name; 


hash = init name hash(); 
// 计 算 当 前 分 量 hash 值 ，dcache 里 组 织 是 以 文件 名 为 基础 的 
do 

namet++; 

hash = partial name hash(c, hash); 

C=* (const unsigned char *)name; 


} while (c && (c != 0))7 
// 计 算 当前 分 量 的 长 度 
this.len = name - (const char *) this.name; 


// 当 前 分 量 hash 值 ， 用 来 在 dcache 里 查找 
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this.hash = end name hash (hash) 7 


type = LRST_NORM; 
// 处 理 “. -”“-?” 的 情况 


i1f (this.namel0] == -7 》 switch (this.len})y { 
case 2: 
if (this.name[1] == '.') { 


type = LAST DOTDOT; 
nd->flags |= LOOKUP JUMPED; 
} 
break; 
case 1: 
type = LAST DOT; 
} 
// 在 目录 nd->path.dentry 查找 this，nd->inode 将 记录 下 查找 结果 的 inode 
err = walk component (nd, é&next, &this, type, LOOKUP FOLLOW); 
// 如 果 没有 lookup 函数 ， 说 明 该 文件 不 是 日 录 文件 ，(break) 
if (!nd->inode->i op->lookup) 
break; 
continue; 


last component: 

”  /* 清楚 LOOKUP_CONTINUE 标志 ， 表 示 查 找 任务 完成 */ 
nd->flags &= lookup flags | ~LOOKUP CONTINUE; 
nd->last = this; 
nd->last type = type; 
return 0; 


static int do lookup(struct nameidata *nd, struct qstr *name, 
struct path *path, struct inode **inode) 


struct vfsmount *mnt = nd->path.mnt; 

/* nd->path.dentry 指向 父 目录 的 struct dentry 结构 ， 该 函数 的 目的 是 在 该 目录 下 
查找 struct qstr *name 文件 */ 

struct dentry *dentry, *parent = nd->path.dentry; 

int need reval = 1; 

int status = 1; 

int err=0; 
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// 先 在 dcache 里 查找 


dentry = __d lookup(parent, name); 


// 没 有 在 dcache 里 找到 ， 去 文件 系统 里 找 
if (unlikely(!'dentry)) { 
// 父 目录 也 是 一 个 inode， 取 出 父 目 录 的 inode 


struct inode *dir = parent->d inode; 


mutex lock(&dir->i mutex); 

// 锁 住 该 目录 后 再 查 一 次 dacahe 
dentry = d_ lookup (parent, name); 
// 依 然 没有 找到 

if (likely(!'dentry)) { 


} 


/* 这 里 再 为 当前 文件 name 分 配 一 个 新 的 struct dentry 并 将 其 挂 载 到 父 


的 struct 1ist head qd _ subdirs; 链 表 里 */ 
dentry = d alloc and lookup (parent, name, nd); 


if (IS ERR(dentry)) { 

// 如 果 没 有 成 功 查 找 ， 解 开 当 前 目录 mutex 锁 ， 返 回 错误 值 
mutex unlock (gdir->i mutex); 
err = PTR ERR(dentry); 
goto end do lookup; 

} 

/* need_reval 为 0 表示 不 需要 更 新 dcache*/ 

need reval = 0; 

//status 为 1， 表 示 成 功 

status = 1; 


// 成 功 查找 ， 解 开 当前 目录 mutex 锁 


mutex unlock (gdir->i mutex); 


} 


// 将 查找 结果 记录 下 来 
path->mnt = mnt; 
path->dentry = dentry; 


OE = 


follow managed(path, nd->flags); 


*inode = path->dentry->d inode; 


static struct dentry *d alloc and lookup (struct dentry *parent, 


struct qstr *name, struct nameidata *nd) 
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目录 
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struct inode *inode = parent->d inode; 
struct dentry *dentry; 
struct dentry *old; 


/* 从 dcache 里 分 配 一 个 新 的 struct dentry*/ 


dentry = d alloc(parent, name); 


/* inode 为 父 目 录 节 点 , 从 里 面 查找 dentry, 对 于 ext4, 目录 节点 的 操作 函数 为 : struct 
inode operations ext4 dir inode operations， 所 以 这 里 导致 ext4_lookup 
函数 的 调用 */ 

old = inode->i op->lookup(inode, dentry, nd); 

if (unlikely(old)) { 

dput (dentry) 
dentry = old; 

} 


return dentry; 


下 面 是 具体 文件 系 的 文件 查找 ， 以 ext4 文件 系统 为 例 ，Ext4 inode 节点 的 查找 有 以 下 


(1) 查找 所 在 目录 的 目录 项 。 
(2) 根据 目录 项 描述 的 节点 号 ， 取 出 inode。 


static struct dentry *ext4 lookup(struct inode *dir, struct dentry *dentry, 


struct nameidata *nd) 


{ 


struct inode *inode; 
struct ext4 dir entry 2 *de; 
struct buffer head *bh; 


/* 在 ext4 的 dir 目录 下 查找 dentry 对 应 的 文件 ， 返 回 的 是 该 文件 在 dir 目录 下 的 目录 项 */ 
bh = ext4 find entryl(dir, &dentry->d name, &de); 
inode = NULL; 
if (bh) { 
//de 即 为 待 查 文件 的 目录 项 ， 从 目录 项 里 取得 该 文件 在 ext4 里 的 文件 号 


_u32 ino = le32 to cpu(de->inode); 


// 取 出 ext4 的 节点 


inode = ext4 iget(dir->i sb, ino); 


: 


return d splice alias(inode, dentry); 
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8.2.2 ”各 层次 操作 函数 的 安装 


VFS 的 层次 设计 ,允许 具体 的 文件 系统 实现 在 每 一 层 既 可 以 实现 替换 默认 操作 的 函数 ， 
也 可 以 使 用 默认 操作 而 完成 其 逻辑 填空 即 可 。 在 文件 打开 的 过 程 ， 要 为 文件 每 一 层 配置 相 
关 操 作 函 数 。 
第 二 层 文 件 操作 函数 ， 该 层 对 应 于 进程 文件 : 
struct file operations { 
struct module *owner; 
// 文 件 操作 指针 定位 
loff t (*llseek) (struct file *, loff t, int) 7; 
// 文 件 读 
ssize t (*read) (struct file *, char _user *, size t, loff t *); 
// 文 件 写 
ssize t (*write) (struct file *, const char _user *, size 七 loff t *); 
// 文 件 异步 读 
ssize t (*aio read) (struct kiocb *, const struct iovec *, unsigned long, 
loff t); 
// 文 件 异 步 写 
ssize t (*aio write) (struct kiocb*, const struct iovec *, unsigned long, 
loff t}s 
// 读 目录 文件 


int (*readdir) (struct file *, void *, filldir 七 ) 7 


// 文 件 map 操作 ， 接 驶 VM 
int (*mmap) (struct file *, struct vm area struct *); 
int (*open) (struct inode *, struct file *); 


}; 


VFS 第 三 层 操 作 函 数 ， 该 层 对 应 于 物理 文件 节点 ， 有 两 个 层面 。 
Inode 层面 操作 : 


struct inode operations { 
// 查 找 目 录 ， 目 录 文 件 节点 须 实现 该 操作 
struct dentry * (*lookup) (struct inode *,struct dentry *, struct 
nameidata *); 
// 跟 进 链接 文件 ， 打 开 文件 时 用 到 


void * (*follow link) (struct dentry *, struct nameidata *) 7 


// 文 件 创建 
int (*create) (struct inode *,struct dentry *,int, struct nameidata *); 


// 删 除 文件 时 使 用 


void (*truncate) (struct inode *); 
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8.3.1 


// 设 置 属性 
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int (*setattr) (struct dentry *, struct iattr *); 


// 获 取 属性 


int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *); 


. 


初 看 起 来 ，inode 操作 列表 没有 为 文件 操作 提供 对 应 的 底层 服务 ， 其 原因 在 与 inode 类 
似 于 一 个 容器 其 成 员 变 量 struct address_space i data; 就 是 page cache 树 ， 所 有 文件 操作 都 
被 转化 为 对 struct address_space 的 操作 : 


struct address space operations { 


/* 写 一 页 ， 产 生 Block 层 提交 ， 严 格 地 来 说 writepage 并 不 属于 VFS 第 三 层 ， 该 函数 主要 
是 提供 给 脏 页 回 写 机 制 以 及 页 面 收缩 机 制 使 用 */ 

int (*writepage) (struct page *page, struct writeback control *wbc); 

// 读 一 页 ， 产 生 Block 层 提交 


int (*readpage) (struct file *, struct page *); 


/* 值 得 一 提 是 direct_ IO， 即使 是 对 于 ext4 这 些 使 用 Page cache 机 制 的 文件 系统 ， 依 然 
可 以 通过 direct_IO 操作 来 避 开 page cache， 这 样 所 有 的 文件 内 容 将 不 会 被 加 到 page 


cache 里 */ 


ssize 七 (*direct_IO) (int, struct kiocb *, const struct iovec *iov, 


loff t offset, unsigned long nr segs); 


}; 


VFS 在 各 个 层面 为 每 种 文件 操作 都 提供 了 自己 的 函数 ，VFS 提供 的 函数 完美 地 实现 了 
上 文 提 到 cache 机 制 ， 事 实 上 Linux 体系 下 的 主流 文件 系统 都 使 用 了 VFS 提供 的 函数 ， 这 
里 面 最 典型 的 例子 就 是 Ext4。 不 过 ,尽管 从 代码 树 上 看 属于 VFS 的 例 程 , 但 是 逻辑 上 ， 这 
些 VFS 提供 的 函数 是 特定 文件 系统 的 一 部 分 。 


8.3 文件 写 


文件 写 框架 


VFS 将 文件 写 分 为 以 下 4 个 基本 动作 。 

(1) 找 出 待 写 入 文件 内 容 对 应 的 逻辑 块 。 

(2) 将 文件 内 容 取出 并 放 入 对 应 的 page cache。 

(3) 将 文件 写 内 容 对 应 的 page 标志 为 脏 ， 且 将 文件 节点 inode 标志 为 脏 ， 并 将 该 节点 


提 


E 入 其 超级 块 的 待 写 回 队列 。 
(4) 检查 内 存 里 脏 页 是 否 到 达 一 定 阔 值 ， 如 果 满 足 条 件 则 唤醒 写 回 deamon。 
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VFS 提供 了 一 个 基础 的 写 框架 的 例 程 static ssize t generic perform write(…)， 代 码 


如 下 : 


//struct iov iter *i 里 存放 着 要 写 入 的 文件 内 容 ，pos 则 为 文件 指针 


static ssize t generic perform write (struct file *file, 


struct iov iter *i, loff t pos) 


/*write_begin 用 来 映射 文件 逻辑 块 或 者 分 配 文件 块 ， 同 时 将 该 page 对 应 的 文件 内 

容 读 进 内 存 */ 

status = a ops->write begin(file, mapping, pos, bytes, flags, 

&page, &fsdata); 
if (unlikely (status)) 
break; 

/*write_begin 会 把 文件 内 容 读 取出 来 ， 这 种 情况 下 有 可 能 进行 DMA 操作 导致 与 L1 
dcache 不 一 致 ， 所 以 要 刷 一 下 L1 dcache， 以 保持 一 致 性 ， 如 果 其 内 容 有 可 能 为 可 
执行 代码 ， 还 要 刷 一 下 L1 icache*/ 

if (mapping writably mapped (mapping) ) 

flush dcache _ page (page) 


pagefault disable(); 

/* 把 文件 内 容 从 用 户 态 读 进 内 核 的 page 里 */ 

copied = iov iter copy from user atomic(page, i, offset, bytes); 

pagefault enable(); 

/* 再 次 刷 1 cache， 这 次 刷 cache 的 原因 不 同 于 上 一 次 ， 这 里 在 于 在 把 文件 内 容 从 用 
户 态 读 进 内 核 的 page 里 的 过 程 中 , 使 用 虚拟 地 址 对 page 进行 了 写 操作 , 这 时 该 page 
的 内 容 有 可 能 还 在 dcache 里 ， 而 这 之 后 有 可 能 对 该 page 做 DMA， 所 以 这 里 也 要 刷 

“Ty 

flush dcache page (page); 

/* 针 对 所 有 的 page cache 里 的 page， 内 核 将 其 按 其 活跃 度 串 在 不 同 的 “活跃 ”或 “不 
活跃 ”队列 ， 在 shrink memory 时 作为 判断 标准 ， 这 里 说 明 该 page 活跃 度 增加 ， 
改变 其 活跃 状态 */ 

mark_page_accessed (page); 

/* 写 操作 的 结束 阶段 ， 写 操作 的 结束 ， 不 等 于 真正 写 回 存储 设备 ， 这 里 只 是 将 其 标志 

为 脏 */ 
status = a ops->write end(file, mapping, pos, bytes, copied, 


page, fsdata); 


// 文 件 指针 迁移 
pos += copied; 
written += copied; 


// 检 查 是 否 到 了 写 回 时 机 
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balance dirty pages ratelimited (mapping); 
// 步 进 struct iov iter 下 一 个 内 容 段 
} while (iov iter count(i)); 
// 返 回 写 入 的 长 度 ， 其 实 是 写 入 到 page cahe 里 的 长 度 


return written ? written : status; 


8.3.2 write_begin 


这 是 写 操作 的 第 一 个 阶段 ， 为 要 写 入 的 文件 内 容 映 射 或 者 分 配 文件 块 。 每 种 文件 系统 
根据 自己 的 特点 实现 各 有 不 同 ， 但 是 几乎 所 有 的 块 设 备 文件 系统 都 使 用 int 
_ block write_ begin(…) 作 为 其 write_begin 的 主体 。 


// 不 同 的 文件 系统 都 需要 提供 自己 的 get_block t *get_block 函数 
int _ block write _ begin(struct page *page, loff t pos, unsigned len, 
get block t *get block) 


// 写 起 始 地 址 ， 这 里 以 页 为 单位 
unsigned from = pos & (PAGE CACHE SIZE-1); 
// 写 终止 地 址 


unsigned to = from + len; 


// 逻 辑 块 的 大 小 
blocksize = 1 << inode->i blkbits; 
// 如 果 page 没有 bh， 要 为 其 创建 bh， 每 个 bh 指向 一 个 逻辑 块 
if (!page has buffers (page)) 

create empty buffers (page, blocksize, 0); 
head = page buffers (page); 


bbits = inode->i blkbits; 
// 算 出 page 对 应 的 文件 系统 起 始 逻 辑 块 号 
block = (sector t)page->index << (PAGE CACHE SHIFT - bbits); 


// 针 对 page 对 应 的 每 一 个 逻辑 块 ， 映 射 或 分 配 磁盘 块 

for (bh = head, block start = 0; bh != head || !block start; 
block++, block start=block end, bh = bh->b this page) { 
block end = block start + blocksize; 


// 如 果 要 写 的 内 容 不 在 这 个 逻辑 块 中 ， 跳 过 
if (block end <= from || block start >= to) { 
if (PageUptodate(page)) { 
if (!buffer uptodate (bh)) 
set buffer uptodate (bh); 
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continue; 
} 
if (buffer new (bh)) 

clear buffer new (bh); 

/* 该 BH 没有 映射 过 , 说 明 其 没有 对 应 的 磁盘 地 址 ,而 其 逻辑 块 对 应 哪个 磁盘 地 址 ， 只 有 
具体 文件 的 文件 系统 才 知 道 */ 

if (!buffer mapped(bh)) { 

// 用 具体 的 文件 系统 映射 函数 ， 取 该 逻辑 块 对 应 磁盘 地 址 
err = get block(inode, block, bh, 1); 
if (err) 

break; 

/* 如 果 这 是 一 个 新 分 配 的 逻辑 块 , 要 在 对 应 的 设备 page cache 树 里 查找 是 否 已 经 存在 。 
出 现 这 种 可 能 性 的 原因 在 于 ， 文 件 系 统 元 数据 使 用 的 设备 文件 的 page cache 树 ， 详 
细 分 析 参 见 在 block 一 章 */ 

if (buffer new(bh)) { 
// 处 理 磁盘 块 同时 挂 载 普通 文件 page cache 和 设备 文件 page cache 的 情况 
unmap_ underlying metadata (bh->b bdev, 
bh->b blocknr); 


/* 如 果 写 入 内 容 落 在 该 逻辑 块 ， 那么 要 把 page 里 对 应 地 方 探 干净 ， 因 为 某 些 
文件 系统 这 时 已 经 读 进 内 容 了 ,而 该 逻辑 块 又 是 新 分 配 的 ， 而 这 个 逻辑 块 有 
可 能 是 别 的 用 户 的 文件 ， 为 了 安全 性 着 想 ， 清 0*/ 

if (block end > to || block start < from) 

Zero_user segments (page, 
to, block end, 
block start, from); 


continue; 


} 


/ /逻辑 块 映射 完毕 ， 且 写 目 标 落 入 该 逻辑 块 ， 下 一 步 要 将 逻辑 块 读 出 来 
if (!buffer uptodate(bh) && !buffer delay(bh) && 
!buffer unwritten(bh) && 
(block start < from || block end > to)) { 
// 提 交 远 辑 块 读 申 请 
1] rw block (READ, 1, &bh); 
// 记 录 下 需要 等 待 的 逻辑 块 
*wait bh++=bh; 
} 
} 
/* 等 待 逻辑 块 读 完毕 再 返回 ， 因 为 下 一 步 要 往 page 里 写 东 西 ， 如 果 不 等 待 update， 就 会 出 错 */ 
while(wait bh > wait) 1{ 
wait on buffer (*-—wait bh); 
if (!buffer uptodate(*wait bh)) 
err = ~EIO; 
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8.3.3 write_end 


本 节 分 析 写 框架 的 write_end 例 程 , 内 核 提供 通用 write_end 例 程 , 基于 内 核 的 static int 
block commit write 工作 可 被 具体 文件 系统 直接 引用 。 


//write_end 例 程 主要 工作 是 脏 页 及 脏 节点 的 提交 
int generic write end(struct file *file, struct address space *mapping, 


loff t pos, unsigned len, unsigned copied, 
struct page *page, void *fsdata) 


struct inode *inode = mapping->host; 
int i size changed = 0; 
// 将 本 次 写 履 盖 范 围 内 所 有 的 页 提交 为 脏 页 ， 参 见 下 文 


copied =block write _end(file, mapping, pos, len, copied, page, fsdata); 


// 文 件 变 长 了 ， 在 inode 里 记录 新 的 文件 长 度 

if (postcopied > inode->i size) { 
i_ size write(inode, postcopied); 
i size changed = 1; 


: 


//inode 本 身 发 生变 化 ， 将 inode 本 身 标志 为 脏 
if (i_ size changed) 

mark inode dirty(inode); 
return copied; 


} 


写 进 page cache 而 有 没有 被 写 回 磁盘 的 page 称 之 为 脏 页 。 文件 写 的 最 后 一 个 动作 是 维 
护 脏 页 ， 代 码 如 下 : 


static int _block commit write(struct inode *inode, struct page *page, 


unsigned from, unsigned to) 


blocksize = 1 << inode->i blkbits; 
/* 针对 page 的 每 一 个 BH 做 两 个 动作 : (1) 是 否 该 BH 已 经 update， 在 block 层 驱 动 在 
BH read 完成 以 后 会 将 该 BH 置 为 UPADTE; (2) 将 该 BH 标志 为 胜 ， 这 将 引起 inode 写 
回 队列 的 变化 ， 见 下 文 详 述 */ 
for (bh = head = page buffers (Page)，block start = 0; 
bh != head || !block start; 
block start=block end, bh = bh->b this page) { 


8.4.1 


} 
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block end = block start + blocksize; 
if (block end <= from || block start >= to) 
// 该 BH 没有 update 

if (!buffer uptodate (bh)) 

partial = 1; 

} else { 

set buffer uptodate (bh); 
// 标 志 该 BH 为 脏 

mark buffer dirty (bh); 
} 


clear buffer nevw(bh); 


// 有 一 逻辑 块 不 为 upadate， 也 不 能 置 为 update 
if (!partial) 


8.4” 脏 页 的 提交 与 回 写 机 制 
脏 页 的 提交 


SetPageUptodate (Page) ; 


脏 页 的 提交 主要 有 以 下 两 种 原因 。 

(1) 文件 系统 的 写 导 致 了 脏 页 ， 在 文件 写 的 最 后 需 提交 脏 页 ， 这 里 还 包括 由 于 文件 增 
长 导致 node 本 身 为 脏 的 提交 。 

(2) VM_SHARED 属性 的 File backed 内 存 发 生 了 写 访 问 。 

文件 写 操作 导致 的 脏 页 提交 的 代码 如 下 : 


// 车 一 个 逻辑 块 为 dirty， 则 整个 page 都 是 dirty 
void mark buffer dirty(struct buffer head *bh) 


E 


// 已 处 于 dirty 状态 ， 返 回 


if (buffer dirty(bh)) { 


} 
// 


smp_mb(); 
if (buffer dirty (bh)) 


return; 


该 BH 第 一 次 被 置 位 为 脏 


if (!test set buffer dirty(bh)) { 


struct page *page = bh->b page; 
// 查 看 对 应 的 page 是 否 为 脏 
if (!TestSetPageDirty(page)) { 


struct address space *mapping = page mapping (page); 
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// 该 page 有 一 个 逻辑 块 为 脏 ， 那 么 该 page 就 处 于 脏 状 态 
if (mapping) 
_ set page dirty(page, mapping, 0); 


// 一 个 文件 里 有 一 个 page 为 脏 ， 那 么 该 文件 也 必定 为 脏 
static void set page dirty(struct page *page, 
struct address space *mapping, int warn) 


// 将 该 文件 节点 标志 为 脏 
_ mark inode dirty(mapping->host, I DIRTY PAGES); 


//inode 节点 脏 使 能 


void _mark inode dirty(struct inode *inode, int flags) 


{ 


struct super block *sb = inode->i sb; 
struct backing dev info *bdi = NULL; 


/*inode 贡 点 本 身 为 脏 ， 经 常 发 生 的 情况 是 文件 长 度 增加 、 属 性 改变 */ 
if (flags & (I_DIRTY SYNC | I_DIRTY DATASYNC)) { 
// 调 用 对 应 超级 块 的 inode 脏 使 能 函数 
if (sb->s_op->dirty inode) 
sb->s_op->dirty inode (inode, flags); 


/* 如 果 inode 状态 与 要 设置 的 状态 一 致 ， 这 没有 必要 再 进行 了 。 一 个 dirty 有 多 个 page， 
多 个 BH， 每 一 次 都 移动 inode 队列 没有 必要 ， 而 且 正如 注释 所 述 ， 将 引起 不 必要 的 
inode->i_lock 竞争 */ 

if ((inode->i state & flags) == flags) 


return; 


// 该 inode 状态 与 要 更 新 的 状态 不 一 至 
spin lock(&inode->i lock); 
if ((inode->i state & flags) != flags) { 
/*inode 有 多 种 状态 ， 这 里 检查 是 否 已 经 处 在 inode 节点 脏 或 是 数据 页 脏 的 情况 ， 
was_dirty 表示 过 去 就 是 脏 的 */ 


const int was dirty = inode->i state & I DIRTY; 
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// 置 位 

inode->i state |= flags; 
/* 

该 节点 正 处 在 SYNC 状态 ， 跳 过 
*/ 


if (inode->i state & I SYNC) 


goto out unlock inode; 


// 该 节点 第 一 次 被 置 为 脏 
if (!was dirty) { 
bool wakeup bdi = false; 
// 索 引 到 该 节点 所 在 的 设备 信息 
bdi = inode to bdi (inode); 
// 检 查 该 节点 是 否 能 写 回 ， 一 般 的 块 设备 都 具备 
if (bdi cap writeback dirty(bdi)) { 


/* 设 备 的 写 回 控制 结构 挂 载 着 设备 当前 的 脏 节点 和 正在 写 回 的 inode 节点 ， 
以 其 是 否 为 空 来 判断 写 回 deamon 的 状态 */ 
if (!wb has dirty io(&gbdi->wb) ) 
wakeup bdi = true; 

} 
// 脏 使 能 关键 的 操作 
spin_unlock(&inode->i_ lock) 
spin lock(&inode wb list lock); 
inode->dirtied when = jiffies; 
// 将 该 节点 挂 载 到 写 回 控制 结构 的 脏 队 列 
list move(&inode->i wb 1ist，&bdi->wb.b dirty); 
spin unlock(&inode wb list lock); 
// 叫 醒 bdi 的 deamon， 参 见 block 一 章 
if (wakeup bdi) 

bdi wakeup thread delayed (bdi); 
return; 


} 
8.4.2 回 写 时 机 


内 核 使 用 回 写 机 制 的 目的 是 减少 磁盘 操作 的 次 数 , 在 一 个 page 的 修改 累积 到 一 定 程度 
再 启动 底层 物理 设备 写 操作 。 回 写 机 制 的 触发 时 机 有 以 下 三 种 。 
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(1) 来 自 文件 写 。 在 文件 写 操作 的 结束 ， 通 常 检查 脏 页 的 状态 是 否 满足 启动 回 写 机 制 
的 条 件 。 

(2) 来 自 File backed 日 VM_SHARED 的 内 存 写 。 在 页 异常 产生 脏 页 的 时 候 也 会 检查 
脏 页 的 状态 是 否 满足 启动 回 写 机 制 的 条 件 ， 而 在 shrink_page_list 时 会 直接 将 脏 页 用 
writepage 提交 到 设备 层 。 

(3) 来自 存储 设备 的 定时 机 制 。 存 储 设备 struct backing_dev_info 在 向 内 核 内 核 注册 自 
身 时 ， 会 启动 一 个 内 核 线程 ， 该 线程 会 定时 醒 来 ， 检 查 并 回 写 该 设备 的 脏 页 。 

除 第 二 个 触发 时 机 的 shrink page list 直接 writepage 的 情况 以 外 ， 触 发 时 机 的 到 来 不 
一 定 会 一 定 触发 回 写 机 制 ， 触 发 时 机 到 来 时 系统 中 脏 页 需要 满足 以 下 条 件 才 会 进一步 触发 
写 操作 的 实际 执行 ， 参 见 如 下 代码 : 

// 触 发 回 写 机 制 的 条 件 检查 


void balance dirty pages ratelimited nr(struct address space *mapping, 


unsigned long nr pages dirtied) 


{ 


/* 第 一 个 条 件 ， 即 触发 时 机 对 应 的 设备 上 的 脏 页 累积 超过 一 定数 量 */ 
if (mapping->backing dev info->dirty exceeded) 
ratelimit = 8; 


/* 

第 二 个 触发 条 件 ， 当 前 处 理 器 上 产生 的 脏 页 是 否 超过 系统 限定 值 ratelimit_pages 
*/ 

preempt disable(); 

// 当 前 处 理 器 上 产生 的 脏 页 计数 

p= & get cpu var(bdp ratelimits); 

// 当 前 处 理 器 上 产生 的 脏 页 累加 

*p += nr pages dirtied; 

// 大 于 阔 值 才 会 启动 回 写 机 制 

if (unlikely(*p >= ratelimit)) { 


balance dirty pages (mapping, ratelimit); 
return; 


} 


第 三 个 触发 时 机 保证 了 在 满足 不 了 上 文 提 到 的 回 写 触发 条 件 的 脏 页 回 写 。 在 一 个 脏 页 
产生 数量 较 少 的 情况 ， 上 一 个 检查 机 制 失效 ， 只 有 通过 定时 机 制 来 保证 其 回 写 了 ， 参 见 如 
下 代码 : 

/* 每 个 struct backing_dev_info 在 注册 时 都 会 创建 以 下 内 核 线程 ， 以 检测 需要 回 写 到 该 设备 

的 脏 页 状态 */ 
static int bdi forker thread (void *ptr) 
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//me 即 为 当前 struct backing dev_info 的 回 写 控制 机 构 


struct bdi _ writeback *me = ptr; 
for (say 


//action 是 针对 当前 脏 页 状态 需要 做 出 的 相关 动作 

enum { 
NO_ACTION, /* Nothing to do */ 
FORK_THREAD, /* Fork bdi thread */ 
KILL THREAD, /* Kill inactive bdi thread */ 


} action = NO ACTION; 


/* 
当前 设备 有 脏 页 待 写 ， 则 回 写 待 回 写 脏 页 

*/ 

if (wb has dirty io(me) || !list empty(&me->bdi->work list)) { 


del timer(&me->wakeup timer); 
wb_do writeback (me, 0); 
} 


/* 检 查 系统 中 的 其 他 struct backing_dev_info 设备 ， 是 否 也 有 待 回 写 脏 页 */ 
list for each entry(bdi, gbdi list, bdi list) { 


bool have dirty io; 


// 该 struct backing dev_info 设备 存在 待 回 写 脏 页 
have dirty io = !list empty(&bdi->work list) || 
wb _ has dirty io(gbdi->wb); 


// 但 是 该 struct backing_dev_info 设备 上 却 没有 活跃 的 回 写 线程 
if (!bdi->wb.task && have dirty io) { 


/*action 指出 需要 在 该 设备 激活 回 写 deamon*/ 
action = FORK_THREAD; 


break; 


// 该 设备 已 无 待 回 写 脏 页 ， 但 是 其 上 还 有 回 写 deamon 
if (bdi->wb.task && !have dirty io && 
time after(jiffies, bdi->wb.last active + 


bdi longest inactive())) { 


// 杀 掉 这 个 无 用 的 回 写 deamon 
action = KILL THREAD; 
break; 
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} 
spin unlock (gbdi->wb lock); 
} 


// 根 据 action 执行 需要 的 操作 
Switch (action) { 
case FORK _ THREAD: 
set current state (TASK RUNNING) 
/* 为 该 struct backing_dev_info 设备 启动 回 写 deamon， 参 数 为 该 设备 的 
写 控制 机 构 */ 
task = kthread _ create (bdi writeback thread, &bdi->wb, 
"flush-ss"，dev_name (bdi->dev) ) 


加 


break; 


case KILL THREAD: 
_ set current state (TASK RUNNING); 
// 杀 掉 无 用 的 deamon 
kthread stop (task) 
break; 


case NO ACTION: 
// 不 需要 回 写 ， 睡 眠 定时 醒 来 


if (!wb has dirty io (me) || !dirty writeback interval) 


schedule timeout (bdi longest inactive()); 

else 
schedule timeout (msecs to jiffies(dirty writeback interval 
* 10)); 

// 检 查 自身 是 否 需要 freeze 

try to freeze(); 

/* Back to the main loop */ 


continue; 


return 0; 


} 

回 写 deamon，bdi_writeback_thread 的 作用 与 bdi_forker_ thread 类 似 ， 也 是 检查 是 否 有 
脏 页 以 执行 回 写 。 但 是 bdi writeback thread 不 同 的 地 方 是 其 仅 针对 当前 struct 
backing_dev_info 设备 ， 而 不 是 整个 struct backing_dev_info 链表 。 
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8.4.3 回 写 机 制 的 层次 操作 


回 写 的 对 象 , 不 是 针对 某 一 个 page 或 文件 ， 回 写 针 对 的 是 一 个 设备 。 所 以 回 写 操作 的 
层次 是 文件 系统 ， 然 后 是 节点 struct address_space， 最 后 才 是 page。 


// 回 写 操作 的 实体 ， 无 论 哪 种 回 写 时 机 都 会 使 用 到 该 函数 
void writeback inodes wbl(struct bdi writeback *wb, 


struct writeback control *wbc) 


人 


int ret = 0; 


// 只 要 该 设备 上 有 需要 回 写 的 page 
while (!list empty(&wb->b io)) { 


// 针 对 该 设备 上 文件 系统 操作 ，sb 即 为 超级 块 


ret = writeback sb inodes(sb, wb, wbc, false); 


. 
// 针 对 一 个 文件 系统 内 的 回 写 
static int writeback sb inodes (struct super block *sb, struct bdi writeback 


*Wwh, 
struct writeback control *wbc, bool only this sb) 


/*wb 为 当前 设备 的 回 写 操作 ， 其 上 的 b_io 队列 是 该 设备 上 的 文件 系统 的 节点 */ 
while (!list empty(&wb->b io)) { 


// 节 点 层次 的 回 写 


writeback single_inode (inode, wbc); 


} 
8.4.4 ”节点 层次 的 回 写 


Inode 是 回 写 机 制 的 基本 单位 ， 内 核 针对 每 个 节点 执行 回 写 操作 。 节 点 回 写 包括 两 方 
面 的 动作 : 一 是 节点 本 身 的 回 写 ， 如 在 文件 增长 时 节点 的 长 度 发 生 改 变 ， 这 时 须 将 节点 本 
身 回 写 ; 二 是 节点 对 应 文件 内 容 的 回 写 ， 即 脏 页 回 写 。 这 两 个 动作 由 一 个 函数 框架 来 完成 ， 
代码 如 下 : 
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/* 
回 写 一 个 节点 ， 包 括 节点 本 身 和 节点 内 容 
本 


static int writeback single inode (struct inode *inode, struct writeback 
control *wbc) 


{ 


// 节 点 内 容 的 回 写 ， 该 函数 将 提交 节点 脏 页 


ret = do _ writepages (mapping, wbc); 


/* 
若 控 制 结构 指示 为 WB_SYNC_ALL， 在 这 里 等 待 该 节点 page 的 writeback 完成 
sf 
if (wbc->sync mode == WB_SYNC ALL) { 
int err = filemap fdatawait (mapping); 


spin lock(&inode->i_ lock); 

/* 

I_DIRTY 指出 inode 本 身 被 修改 
*/ 

dirty = inode->i state & I DIRTY; 

inode->i state &= ~(I DIRTY SYNC | I_DIRTY DATASYNC); 

spin unlock (ginode->i lock); 

/* 这 里 将 回 写 inode 本 身 。 作 为 文件 系统 元 数据 ， 只 有 具体 的 文件 系统 才 知 道 ， 如 何 回 写 
inode 本 身 ， 这 里 调用 其 超级 块 操 作 函 数 : int (*write inode) (struct inode *, 
struct writeback control *wbc); */ 

if (dirty & (I_DIRTY SYNC | I_DIRTY DATASYNC)) { 

int err = write inode (inode, wbc); 


i 


/* 

基础 的 节点 内 容 回 写 函 数 ， 主 要 执行 具体 文件 系统 提供 的 writepages 函数 , 车 具体 的 文件 系统 没 
有 提供 该 函数 ， 则 执行 内 核 默 认 例 程 。 事 实 上 一 些 文件 系统 尽管 提供 了 自己 的 writepages 函数 ， 
但 其 实现 还 是 以 调用 内 核 默 认 例 程 为 主 。 本 文 着 重 分 析 内 核 默 认 例 程 


a 
int do writepages (struct address space *mapping, struct writeback control 
*wbc) 
{ee 
// 如 果 具 体 的 文件 系统 提供 writepages 函数 则 使 用 
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if (mapping->a ops->writepages) 

ret = mapping->a ops->writepages (mapping, wbc); 
else 
// 和 否则 ， 使 用 内 核 默 认 的 节点 回 写 机 制 

ret = generic writepages (mapping, wbc); 


return ret; 


/* 将 一 个 inode 的 页 面 提交 到 block 层 ，mapping 为 该 inode 对 应 的 page cache 树 ，wbc 
为 当前 写 回 操作 的 控制 模式 */ 


int generic writepages(struct address space *mapping, 


struct writeback control *wbc) 


struct blk plug plug; 
int ret; 


/* 如 果 该 inode 所 属 文件 系统 没有 实现 writepage 例 程 ， 则 这 种 页 面 回 写 方式 无 法 使 用 ， 
不 过 对 于 大 部 分 文件 系统 都 基于 内 核 基础 函数 block_write_full_page 实现 了 该 例 程 */ 
if (!mapping->a ops->writepage) 
return 0; 


blk start plug(&plug); 
/* 将 该 inode 所 有 状态 为 脏 的 页 面 收集 起 来 ,然后 依次 对 其 执行 lock 操作 ,然后 调用 writepage 
例 程 将 该 页 写 回 ， 在 writepage 例 程 里 ， 在 完成 页 面 的 BH 提交 后 将 对 该 page unlock*/ 
ret = write cache pages (mapping, wbc, _ writepage，mapping) 
blk finish plug(&plug); 
return ret; 


/* 

将 一 个 节点 的 脏 页 回 写 出 去 

*/ 

int write cache pages (struct address_ space *mapping, 


struct writeback control *wbc, writepage t writepage, 
void *data) 


// 从 该 节点 第 一 个 脏 页 面 开始 回 写 脏 页 面 ， 直 到 完成 


while (!dqone && (index <= end)) 1{ 


// 在 该 节点 的 page cache 里 取出 一 定数 量 的 脏 页 
nr pages = pagevec_lookup_tag(&pvec，mapping，&index，tagv 
min (end - index, (pgoff t)PAGEVEC SIZE-) + 1); 
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// 依 次 处 理 取出 的 每 一 个 page 
for (i = 0; i < nr pages; i++) { 
struct page *page = pvec.pages[il]; 


// 检 查 该 页 是 否 为 脏 ， 否 则 也 没有 必要 将 其 回 写 了 
if (!PageDirty(page)) { 


} 
// 该 页 已 经 处 于 写 回 状态 ， 只 要 控制 结构 允许 ， 等 待 其 完成 
if (PageWriteback(page)) { 
if (wbc->sync mode != WB_SYNC NONE) 
wait on page writeback (page); 


else 
goto continue unlock; 


} 


// 脏 页 监控 机 制 的 一 环 ， 参 见 脏 页 监控 机 制 
if (!clear page dirty for io (page) ) 
goto continue unlock; 


// 调 用 具体 文件 系统 writepage， 将 脏 页 提交 到 block 层 


ret = (*writepage) (page, wbc, data); 


} 


/* 将 一 个 页 面 提交 到 Block 层 ，get_block 为 该 文件 系统 的 映射 函数 */ 
int block write full page(struct page *page, get block t *get block, 
struct writeback control *wbc) 


// 实 现 主体 是 static int _block write full page (…) 函数 
return block write full page endio(page, get block, wbc, 


将 一 个 页 提交 给 Block 的 说 法 不 是 很 准确 , 向 Block 提交 的 基本 单位 是 BH, 一 个 page 
对 应 可 能 对 应 多 个 BH， 但 是 重点 分 析 基 于 emmc+ext+4k 文件 块 的 栓 入 式 及 手机 系统 ， 所 
以 这 里 一 个 BH 对 应 一 个 page。 

/* 


页 面 提交 函数 ， 该 函数 是 内 核 为 writepage 提供 的 基础 例 程 ， 供 具体 的 文件 系统 选择 使 用 
*/ 
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static int _block write full page (struct inode *inode, struct page *page, 
get block t *get block, struct writeback control *wbc, 
bh end io t *handler) 


// 一 个 文件 块 的 大 小 


const unsigned blocksize = 1 << inode->i blkbits; 


// 该 文件 最 后 一 个 文件 逻辑 块 号 


last block = (i size read(inode) -1) >> inode->i blkbits; 


/* 如 果 该 page 没有 BH， 则 为 其 创建 ， 对 于 ext4 文件 系统 ， 在 这 个 工作 在 写 框架 的 第 一 步 
就 已 经 完成 了 */ 
if (!page has buffers(page)) { 
create empty buffers (page, blocksize, 
(1 << BH Dirty)|(1 << BH Uptodate)); 
} 


/* 当前 page 对 应 的 起 始 逻辑 文件 块 号 */ 


block = (sector t)page->index << (PAGE CACHE SHIFT - inode->i blkbits); 
head = page buffers (page); 
bh = head; 


/* 针 对 每 个 文件 罗 辑 块 ， 寻 找 其 对 应 的 文件 系统 物理 块 号 ， 对 于 不 同文 件 系统 这 时 有 不 同情 
形 ， 而 对 于 ext4 系统 ， 尽 管 在 其 写 框 架 的 第 一 步 就 做 了 映射 ， 但 是 有 的 文件 系统 在 页 面 
提交 时 才 会 做 映射 ， 代 码 的 这 个 位 置 需要 提供 较为 generic 操作 ， 所 以 为 了 兼容 别 的 文件 
系统 。 这 里 会 再 一 次 映射 以 取得 物理 块 号 ， 而 对 于 ext4 系统 这 里 不 过 就 是 在 cache 里 再 
取 一 次 罢了 ， 并 不 需要 再 次 启动 磁盘 操作 

有 

dof{ 

if (block > last block) { 


/* 已 经 越过 了 文件 长 度 ， 但 是 还 有 新 的 BH， 这 种 情况 发 生 在 文件 块 大 于 或 小 于 
page， 且 文件 总 长 度 的 最 后 一 个 文件 块 不 能 对 应 最 后 一 个 page 的 最 后 一 个 文件 
块 。 这 是 没有 意义 的 文件 块 ， 清 除 其 脏 状态 

A 

clear buffer dirty (bh); 

set buffer uptodate (bh); 

} else if ((!buffer mapped(bh) || buffer delay(bh)) && 
buffer dirty(bh)) { 

/ /映射 物 理 块 ， 这 一 次 一 定 要 取得 物理 块 号 

err = get block(inode, block, bh, 1); 

if (err) 


goto recover; 
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clear buffer delay (bh); 
if (buffer new(bh)) { 
/* 查 看 新 分 配 的 文件 块 是 否 在 bdev 文件 系统 节点 里 , metadata 占用 物理 块 
的 重新 分 配 有 可 能 导致 这 种 情况 */ 


clear _ buffer new(bh); 


unmap underlying metadata (bh->b bdev, 
bh->b blocknr); 


} 
bh = bh->b this page; 
blockt+t+; 

} while (bh != head); 


dof{ 


if (wbc->sync mode != WB _ SYNC NONE) { 

// 控 制 结构 要 求 真正 写 存储 设备 ，lock 该 BH 
lock buffer (bh); 

} else if (!trylock buffer(bh)) { 

// 控 制 结构 没 要 求 真正 写 存 储 设备 ， 如 果 lock 不 住 该 BH， 将 其 重新 置 脏 
redirty page for writepage (wbc, page); 
continue; 

} 

if (test clear buffer dirty(bh)) { 

// 将 该 BH 的 完成 handler 置 为 end_buffer async write 
mark buffer async write endiol(bh, handler); 

} else { 

// 有 人 在 lock 该 BH 时 已 经 把 BH 写 进 存 储 设备 了 
unlock buffer (bh); 

} 

} while ((bh = bh->b this page) != head); 


/* 

将 要 提交 Block 层 ， 该 page 属于 writeback 状态 
*/ 

set page writeback (page); 


do 1{ 
struct buffer head *next = bh->b this page; 
if (buffer async write(bh)) { 
// 提 交 到 Block 层 
Submit_bh (write op, bh); 


nr underwaytt+; 
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bh = next; 
} while (bh != head); 
// 解 锁 该 page 
unlock page (page); 


err = 0; 
done: 

if (nr underway == 0) { 
/* 
该 page 没有 需要 提交 的 BH， 这 发 生 在 有 别 的 线程 完成 BH 的 写 回 动作 ， 或 者 控制 结构 
不 要 求 sync， 且 该 页 所 有 BH 都 无 法 lock 的 情况 

*/ 

end page writeback (page); 

} 


return err; 


} 


在 该 页 面 的 写 回 完成 后 ,block 层 会 依次 对 完成 BH 调用 void end_buffer async_write(…) 
函数 ， 代 码 如 下 : 
/* 


* Completion handler for block write full page() - pages which are unlocked 
* during I/O0, and which have PageWriteback cleared upon I/O completion. 
*/ 

void end buffer async write(struct buffer head *bh, int uptodate) 


{ 


// 该 BH 对 应 的 page 
page = bh->b page; 
if (uptodate) { 
/* 更 新 BH 状态 为 uptodate, BH 的 uptodate 与 page 的 uptodate 不 同 , 前 者 在 写 
回 完成 才 处 于 update， 后 者 在 脏 时 就 认为 update 了 */ 
set buffer uptodate (bh); 
} else { 


//IO 出 错 ， 不 考虑 这 种 情况 


first = page buffers (page); 

local irq save(flags); 

bit spin lock(BH Uptodate Lock, &first->b state); 
// 清 除 该 BH 的 async 标志 ， 解 锁 该 BH 

clear buffer async write(bh); 

unlock buffer (bh); 

tmp = bh->b this page; 
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// 沿 着 该 page 的 BH 转 一 圈 ， 看 还 有 没有 完成 写 回 的 BH 
while (tmp != bh) { 
if (buffer async write(tmp)) { 
// 还 有 BH 在 写 回 过 程 中 
goto still busy; 


} 

tmp = tmp->b this page: 
} 
// 该 页 所 有 的 BH 都 完成 了 写 回 
bit spin unlock(BH Uptodate Lock，&first->b state); 
local irq restore(flags); 
// 结 束 该 page 的 writeback 状态 
end page writeback (page); 


return; 


} 

以 上 分 析 的 页 提交 是 异步 页 提交 , 再 提交 到 block 层 之 后 当前 线程 就 去 忙 别 的 事情 了 ， 
比如 写 回 deamon 和 日 志 deamon, 它们 不 可 能 每 次 提交 都 等 待 完成 之 后 再 做 下 一 步 的 工作 ， 
那样 太 耗 时 了 。 还 有 一 种 block 提交 是 同步 提交 ， 即 提交 到 block 后 该 线程 就 等 待 该 BH 完 
成 再 做 别 的 。 
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9.1 Android 文件 系统 的 选择 


在 Android 被 大 量 采 用 骨 入 式 及 手机 系统 中 ， 文 件 系统 的 选择 往往 跟 存 储 介 质 有 直接 

若 系 统 使 用 nand 作为 其 存储 介质 。 在 nand 上 构建 文件 系统 有 两 种 方式 ， 对 于 小 规模 
容量 的 nand 芯片 (笔者 认为 在 512M 字 节 以 下 )， 可 以 选择 yffs2 作为 其 文件 系统 。 对 于 较 
大 容量 的 nand 芯片 ， 宜 选用 UBIFS 作为 其 文件 系统 。 这 两 种 基于 nand 的 文件 系统 之 上 都 
可 以 构建 Android 系统 。 

但 是 ，Android 设备 ， 无 论 如 何 都 不 能 选择 Jffs2 作为 其 文件 系统 。 其 直接 原因 是 Jffs2 
没有 能 够 提供 Android 系统 需要 的 int (*fiemap)(s…); 机 制 。 其 原因 在 于 ， 不 同 于 yffs2 和 
ubifs，Jffs2 直接 架构 在 mtd char 设备 上 ， 文 件 布局 设计 为 每 次 写 操作 都 作为 一 个 新 的 数据 
节点 附加 在 文件 系统 后 部 ， 工 作 时 需要 加 载 并 维护 所 有 的 数据 节点 。 每 次 写 操作 都 涉及 数 
据 节点 的 分 割 和 合并 。 且 其 实现 的 时 候 需要 直接 处 理 nand 设备 的 特性 , 需要 在 文件 系统 层 
面 实现 磨损 均衡 、 节 点 合并 等 操作 ， 使 得 Jffs2 维护 其 数据 节点 工作 更 加 复杂 。 对 于 VFS 
读 框架 ，Jffs2 还 可 以 很 好 的 适应 。 但 是 对 于 VFS 写 框架 Jffs2 就 无 法 完整 适 配 ， 每 次 写 操 
作 都 需要 直接 操作 到 Jffs2 维护 的 数据 节点 ， 以 至 于 不 能 提供 writepage 机 制 ， 导 致 flemap 
依赖 的 脏 页 回 写 机 制 无 法 工作 ， 自 然 无 法 支持 flemap 机 制 。 尽 管 如 此 ， 作 为 最 早 被 嵌入 
式 Linux 大 量 使 用 的 nand 文件 系统 ，Jffs2 在 小 型 、 写 操作 不 频繁 的 嵌入 式 系统 中 ， 由 于 
其 高 效 、 稳 定 ， 仍 不 失 最 佳 选择 。 

若 系 统 使 用 EMMC、SD 卡 、SSD 等 基于 nand 的 块 设备 ， 由 于 这 些 设 备 的 工作 特性 已 
经 非常 接近 磁盘 了 , 所 以 其 上 的 文件 系统 的 首选 自然 是 EXT4。 作 为 传统 的 EXT2/3 文件 系 
统 的 演进 ，EXT4 是 Linux 社区 支持 最 好 的 块 设备 文件 系统 之 一 ， 能 全 面 发 挥 内 核 特 性 。 


9.2 EXT4 文件 节点 


本 节 分 析 EXT4 文件 节点 的 基本 结构 、 布 局 和 获取 方式 。 
9.2.1 EXT4 inode 基础 结构 


EXT4 文件 系统 的 inode 结构 定义 在 struct ext4_inode: 
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struct ext4 inode { 


_ lel6 i mode; /*File mode */ 
_ lel6 i uid; /*Low 16 bits of Owner Uid */ 
_ lel6 i gid; /*Low 16 bits of Group Id */ 


/* 普 通 文件 或 者 目录 文件 用 于 文件 块 索引 ， 特 殊 文件 可 以 另 作 它 用 */ 
_ le32 i block[EXT4 N BLOCKS];/*Pointers to blocks */ 


}; 
如 果 用 于 文件 块 索引 ，i_block[] 数 组 的 使 用 分 成 4 个 部 分 : 


// 前 12 项 直接 映射 

#define EXT4 NDIR BLOCKS 12 

// 第 EXT4_IND_BLOCK 项 指向 间接 映射 

#define EXT4 IND BLOCK EXT4_NDIR BLOCKS 

// 第 EXT4_DIND_BLOCK 项 指向 2 次 间接 映射 

#define EXT4 DIND BLOCK (EXT4_IND BLOCK + 1) 
// 第 EXT4_TIND_BLOCK 项 指向 3 次 间接 映射 

#define EXT4 TIND BLOCK (EXT4_DIND BLOCK + 1) 
#define EXT4 N_ BLOCKS (EXT4_TIND BLOCK + 1) 


9.2.2 ”EXT4 raw inode 的 定位 


EXT4 raw inode 指 的 是 EXT4 文件 节点 在 存储 介 上 的 表示 ， 其 布局 可 以 通过 其 inode 
定位 函数 清楚 的 体现 出 来 。int ext4_get_inode loc(…) 是 EXT4 inode 的 定位 函数 ,该 函数 
通过 给 定 的 inode 号 ， 将 对 应 在 EXT4 文件 系统 里 的 inode 提取 出 来 。 


//inode->i_ino 为 该 文件 在 ext4 文件 系统 上 的 节点 号 
static int _ ext4 get inode loc(struct inode *inode, 
struct ext4 iloc *iloc, int in mem) 


struct ext4 group desc *gdp; 
struct buffer head *bh; 
//inode->i_sb; 指 向 ext4 文件 系统 的 超级 块 


struct super _ block *sb = inode->i sb; 
ext4 fsblk 七 block; 


int inodes per block, inode offset; 
iloc->bh = NULL; 
// 检 查 该 节点 是 否 为 有 效 ext4 节点 号 


if (!ext4 valid inum(sb, inode->i ino)) 


return -EIO; 
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/#EXT4_INODES_PER GROUP (sb) 记录 了 一 个 块 组 里 有 多 少 节点 ， 节 点 号 除 以 块 组 节点 数 ， 
得 到 该 节点 位 于 的 块 组 号 */ 
iloc->block group = (inode->i ino - 1) / EXT4 INODES PER GROUP (sb) 


/* 根 据 块 组 号 取出 块 组 描述 符 ， 该 描述 里 记录 了 本 块 组 的 节点 表 的 起 始 块 号 */ 
gdp = ext4 get group desc(sb, iloc->block group, NULL); 
if (!gdp) 

return -EIO; 


/* 
inodes_per_block 表示 每 个 ext4 block 里 能 放 多 少 节点 
*/ 


inodes per block = EXT4 SB(sb)->s inodes per block; 


/*inode_offset 为 节点 号 与 每 块 组 节点 数 的 余数 ， 即 为 节点 号 在 自己 所 在 块 组 的 偏 移 量 ， 
等 于 把 前 面 块 组 的 节点 数 一 一 减 去 */ 
inode offset = ((inode->i ino - 1) %$ 

EXT4_INODES_ PER GROUP (sb)); 


/*ext4 inode_ table (sb，gdp) 为 该 块 组 的 inode 节点 表 起 始 地 址 ，inode_offset 
除 以 每 块 组 所 包含 节点 数 可 以 得 到 自己 所 在 块 号 */ 
block = ext4 inode table(sb, gdp) + (inode offset / inodes per block); 


/* 所 在 块 号 的 偏 移 量 ， 即 为 从 所 在 块 到 自己 节点 之 前 的 节点 数 */ 
iloc->offset = (inode offset % inodes per block) * EXT4 INODE SIZE(sb); 


/* 启 动 块 设备 驱动 ， 把 节点 所 在 块 取出 来 */ 
bh = sb _ getblk(sb, block); 


has_buffer: 
iloc->bh = bh; 
return 0; 


} 


9.2.3 EXT4 inode 的 获取 


要 处 理 文件 就 得 知道 文件 在 磁盘 上 的 具体 构造 ， 这 就 需要 获得 其 磁盘 上 的 节点 信息 ， 


为 VFS 提供 节点 获取 函数 是 文件 系统 实现 的 必要 工作 。EXT4 提供 的 磁盘 节点 获取 函数 为 
ext4 iget。 工 作 时 VFS 通过 ext4 iget 函数 来 获取 EXT4 raw inode 的 信息 ， 并 将 其 与 VFS 
统一 的 节点 管理 机 构 inode 接 驳 起 来 。 


/ /根据 超级 块 和 节点 号 获取 节点 


struct inode *ext4 iget(struct super block *sb, unsigned long ino) 
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struct ext4 iloc iloc; 

//ext4 raw inode 

struct ext4 inode *raw inode; 
struct ext4 inode info *ei; 
// 内 核 统一 的 文件 节点 管理 


struct inode *inode; 


inode 


/* 导 致 static struct inode *ext4 alloc inodqe (struct super block *sb) 被 调 
用 ， 该 函数 分 配 struct ext4 inode_ info 结构 ， 并 返回 其 成 员 变 量 struct inode 
vfs_inode; 的 指针 。 接 着 该 struct inode 被 加 入 到 inode cache, 而 inode cache 
是 挂 载 超 块 上 一 个 hash 表 */ 

inode = iget locked(sb, ino); 

//struct ext4 inode info 被 ext4 节点 分 配 函 数 分 配 

ei = EXT4 I (inode); 

iloc.bh = NULL; 


// 定 位 并 读 取 ino 所 在 的 block 
ret = ext4 get inode locl(inode, &iloc, 0); 
if (ret < 0) 
goto bad inode; 
//iloc->bh->b_data 为 块 起 始 地 址 ，iloc->offset 为 raw inode 在 block 的 偏 移 量 
raw_inode = ext4 raw inode (&iloc)7 
// 把 raw inode 的 信息 放 到 inode 里 
inode->i mode = lel6 to cpul(raw inode->i mode); 
inode->i uid = (uid t)lel6 to cpul(raw inode->i uid low); 
inode->i gid = (gid t)lel6 to cpul(raw inode->i gid low); 


// 关 键 信 息 ， 文 件 块 的 extent tree 的 入 口 

for (block = 0; block < EXT4 N BLOCKS; block++) 
ei->i data[lblock] = raw inode->i block[block]; 

INIT LIST HEAD(&ei->i orphan); 


/*ext4 file operations, ext4 file inode operations、 address space_ 
operations 三 级 文件 操作 函数 指针 ， 内 核 MM 和 VES 搭 出 了 架子 ， 具 体 实现 由 具体 的 文件 系 
统 来 选择 */ 
if (S_ISREG (inode->i_ mode)) { 
// 常 规 文件 
inode->i op = &ext4 file inode operations; 
inode->i fop = &ext4 file operations; 
ext4_ set aops (inode); 
} else if (S ISDIR(inode->i mode)) { 


// 目 录 文 件 


inode->i op = &ext4 dir inode operations; 


第 9 章 EXT4 文件 系统 195 
inode->i fop = &ext4 dir operations; 
} else if (S ISLNK(inode->i mode)) { 
// 链 接 文 件 
if (ext4 inode is fast symlink(inode)) { 
inode->i op = &ext4 fast symlink inode operations; 
nd terminate link(ei->i data, inode->i size, 
sizeof (ei->i data) - 1); 
} else { 
inode->i op = &ext4 symlink inode operations; 
ext4 set aops (inode); 
} 
} else if (S ISCHR(inode->i mode) 


S_ISFIFO(inode->i mode) || S$ ISSOCK(inode->i mode)) { 
// 设 备 文件 ， 设 备 文件 的 i_block[] 数 组 有 特殊 用 途 
inode->i op = &ext4 special inode operations; 
if (raw inode->i block[0]) 


11 S_ISBLK(inode->i mode) 11 


init special inode(inode, inode->i mode, 


old decode dev(le32 to cpul(raw inode->i block[0]))); 
else 


init special inode(inode, inode->i mode, 


new_decode dev(le32 to cpul(raw inode->i block[1]))); 
} else { 


/* 用 来 读 取 raw inode 的 struct buffer_head 使 用 完毕 了 ， 引 用 计数 减 一 ， 参 见 块 
设备 一 章 */ 


brelse (iloc.bh); 

ext4 set inode flags (inode); 
unlock new inode (inode); 
return inode; 


9.3 Mount 


文件 系统 的 加 载 已 经 被 业界 广泛 研究 ， 本 书 不 更 述 。 对 于 EXT4 文件 系统 ， 本 文 仅 关 
心 EXT4 mount 过 程 的 两 个 动作 一 一 文件 超级 块 的 获取 和 日 志 的 加 载 。 前 者 涉及 bdev 文件 
系统 操作 的 一 个 实例 ， 后 者 说 明了 文件 系统 结构 。 


static int ext4 fill super(struct super block *sb，void *data, int silent) 
_ Freleases (kernel] lock) 


__ acquires (kernel lock) 
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/* 读 出 EXT4 超级 块 ， 将 整 块 分 区 作为 一 个 Inode 节点 ， 基 于 VFS inode 操作 的 基础 框架 。 
不 同 的 是 不 需要 做 文件 逻辑 块 到 磁盘 物理 块 的 映射 ， logical_sb_block 直接 指出 了 超级 块 
的 位 置 */ 

if (!(bh = sb bread(sb, logical sb block))) { 


} 
/* 
bh->b_data 指向 超级 块 的 起 始 地 址 ，offset 为 超级 块 的 偏 移 地 址 
*/ 
es = (struct ext4 super block *) (((char *)bh->b data) + offset); 


//EXT4 超级 块 里 记录 其 文件 块 的 大 小 
blocksize = BLOCK SIZE << le32_to_cpu(es->s_1og _ block size) 7 


// 加 载 日 志 
if (ext4 load journal(sb, es, journal devnum)) 
goto failed mount3; 


} 


/* 根 据 EXT4 文件 系统 的 设计 文档 ， 其 日 志 可 以 作为 一 个 普通 文件 放 在 EXT4 文件 系统 的 内 部 ， 也 
可 以 另 辟 一 个 块 设备 来 存放 */ 


static int ext4 load journal (struct super block *sb, 
struct ext4 super block *es, 


unsigned long journal devnum) 


journal t *journal; 

/* 如 果 日 志 作 为 EXT4 文件 系统 的 一 部 分 ，s_journal inum 记录 了 其 文件 号 ， 否 则 其 日 志 
被 放 在 块 设备 s_journal _dev 中 */ 

unsigned int journal inum = le32 to cpul(es->s journal inum); 

dev t journal dev; 

int err = 0; 

int really read only; 


if (journal inum) { 
// 从 EXT4 文件 系统 内 部 将 日 志 控制 结构 读 取 进 来 
if (!(journal = ext4 get journal(sb, journal inum))) 
return-EINVAL; 
} else { 
/* 从 块 设 备 journal_dev 上 将 日 志 控 制 结构 读 取 进来 ， 操 作 bderv 文件 系统 节点 的 又 
-实例 */ 
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if (!(journal = ext4 get dev journal(sb, journal dev))) 
return -EINVAL; 


if (!err) { 


// 日 志 加 载 的 主体 ，Recovery 工作 在 这 里 进行 


err = jbd2 journal load(journal); 


return 0; 


9.4 EXT4 文件 写 操作 


EXT4 写 操作 采用 了 内 核 提 供 的 通用 写 例 程 static size_t generic_perform_ write(-) (不 考 
虑 O_DIRECT 模式 写 )， 针 对 该 例 程 EXT4 需要 为 其 提供 如 下 子 例 程 。 

(1) ext4_da_write_ begin: 实现 逻辑 块 到 物理 块 的 映射 与 分 配 、 将 文件 对 应 内 容 读 进 内 
存 ， 并 启动 日 志 操 作 。 

static int ext4 da write begin(struct file *file, struct address_space 

*mapping, 


loff t pos, unsigned len, unsigned flags, 
struct page **pagep, void **fsdata) 


retry: 
// 启 动 本 次 日 志 操作 


handle = ext4 journal start (inode, 1); 


// 获 取 或 创建 对 应 的 page cache 树 里 的 页 面 


page = grab cache page write begin(mapping, index, flags); 


// 将 该 页 面 的 内 容 读 进 内 存 
ret = _ block write begin(page, pos, len, ext4 da get block prep); 


return ret; 
} 
(2) ext4_da_write_ end: 向 回 写 deamon 提交 脏 页 ， 并 结束 日 志 操作 。 


static int ext4 da _ write end(struct file *file, 


struct address_ space *mapping, 
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loff t pos，unsigned len, unsigned copied, 
struct page *page, void *fsdata) 


// 本 次 写 对 应 的 handle 
handle t *handle = ext4 journal current handle(); 


new i size = pos + copied; 
/* 本 次 写 操作 导致 了 文件 内 容 的 增长 ， 需 要 修改 该 节点 size 值 , 这 就 需要 对 元 数据 进行 修改 ， 
而 对 于 EXT4 的 ordered 模式 ,数据 是 需要 先 于 元 数据 被 写 入 日 志 里 的 ,所 以 在 这 里 将 inode 
做 特殊 处 理 ， 使 得 日 志 deamon 能 够 在 合适 的 时 机 提交 其 数据 页 */ 
if (new i size > EXT4 I(inode)->i disksize) { 
if (ext4 da should update i disksize(page, end)) { 
down write(&EXT4 I (inode)->i data sem); 
if (new i size > EXT4 I(inode)->i disksize) { 
// 节 点 size 改动 的 情况 下 检查 是 否 是 order 模式 
if (ext4 should order data(inode)) 
/* 向 日 志 系 统 提交 该 inode， 该 inode 被 挂 载 进 t_inode_1ist 队列 ， 这 将 
导致 该 jbd2 对 于 文件 内 容 页 的 block 层 的 写 提交 。 由 此 可 见 ，EXT4 ordered 
只 在 文件 增长 时 才 力 图 确保 文件 内 容 被 写 入 文件 系统 的 时 间 先 于 元 数据 被 JBD2 
日 志 的 时 间 ， 这 样 才能 保证 恢复 时 不 至 于 将 别 的 文件 内 容 误 恢复 进来 ， 不 仅 文件 
系统 结构 错误 而 且 将 导致 严重 的 安全 漏洞 。 而 在 文件 内 容 修改 时 ，ordereqd 其 
元 数据 没有 动 ， 所 以 也 没有 必要 将 其 挂 在 +_inode 1ist 队列 了 */ 
ret = ext4 jbd2 file _inode (handle， 
inode); 


EXT4 I(inode)->i disksize = new i size; 
} 
up_write (gEXT4 I(inode)->i data sem); 


/* 在 日 志 里 为 该 inode 分 配 空间 ， 并 以 metadata 形式 向 日 志 提 交 该 inode， 这 将 
导致 该 inode 节点 的 被 写 入 日 志 */ 
ext4 mark inode dirty(handle, inode); 


+ 


3 
/* 将 该 页 置 为 脏 状 态 ， 若 inode size 发 生 改变 ， 这 里 也 将 inode 置 为 脏 状 态 ， 这 是 正常 的 
文件 脏 页 提交 ， 就 相当 于 JBD2 不 存在 一 样 */ 
ret2 = generic write endl(file, mapping, pos, len, copied, 
page, fsdata); 


// 结 束 并 在 需要 的 时 候 同 步 本 次 日 志 操作 
ret2 = ext4 journal stop(handle); 
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9.S EXT4 journal 


志文 件 系统 实现 是 一 个 各 方面 权衡 的 结果 ， 既 要 保证 文件 系统 吞吐 速度 又 要 保证 其 
可 恢复 性 。 任 何 一 种 极端 的 追求 都 不 是 通用 日 志文 件 系 统 实现 的 目标 。 若 要 追求 极端 的 可 
恢复 性 ， 需 将 导致 大 量 元 余数 据 的 写 入 ， 这 将 影响 吞吐 速度 并 且 占 用 大 量 空间 ， 同 时 导致 
文件 碎片 的 大 量 的 产生 ， 这 将 使 得 每 次 文件 系统 的 加 载 好 用 大 量 的 内 存 和 时 间 。 笔 者 认为 
极端 的 可 恢复 性 不 是 通用 文件 系统 的 应 用 领域 ， 只 有 专门 设计 的 软 硬 一 体系 统 才能 满足 这 
个 目标 。 而 元 数据 在 文件 系统 里 起 到 提纲 者 领 的 作用 ， 元 数据 完好 则 系统 极 大 程度 上 是 可 
恢复 的 ， 对 于 常规 嵌入 式 系统 、 手 机 系统 ， 将 文件 系统 元 数据 备份 即 可 。 而 元 数据 使 用 的 
前 提 是 其 对 应 的 文件 数据 能 够 安全 ， 不 然 恢复 出 来 的 肯定 是 错误 的 数据 ;再 者 元 数据 所 在 
位 置 一 般 不 与 数据 连续 在 一 起 ， 将 两 者 分 开 写 无 论 对 于 磁盘 上 的 文件 系统 物理 布局 还 是 
Block 层 电 梯 算 法 都 是 相宜 的 ， 所 以 笔者 认为 ordered 模式 是 最 佳 日 志 模 式 ， 本 文 仅 讨论 
ordered 模式 ， 这 也 是 大 量 被 手机 、 和 嵌入 式 系统 采用 的 模式 。 

JBD2 的 日 志 操作 的 核心 是 struct transaction s 结构 ， 它 是 文件 系统 与 JBD2 的 交互 的 
枢纽 。 一 方面 ， 文 件 系 统 将 需要 写 入 JBD2 空间 的 元 数据 ， 相 关联 的 文件 数据 挂 在 struct 
transaction s 结构 相关 链表 上 ; 另 一 方面 , JBD2 的 kjournald2 线程 把 挂 在 struct transaction_s 
上 的 元 数据 列表 ， 文 件数 据 列表 的 操作 列表 取出 来 ， 或 写 入 文件 系统 ， 或 写 入 JBD2 LOG 
空间 ， 并 控制 其 写 入 顺序 。 

EXT4 的 日 志 操作 购 在 其 写 框架 里 ， 以 一 个 文件 内 容 写 为 例 ，EXT4 的 ordered 模式 日 
志 处 理 关 键 动作 如 下 。 

(1) 在 write begin(…) 中 调用 handle t *ext4 journal start(…)， 创 建 当 前 struct 
jbd2_journal handle， 并 将 其 关联 到 当前 活动 的 struct transaction_s 结构 。 

(2) 若 发 生 文件 增长 ， 调 用 int _ext4_handle_dirty_metadata(…) 将 牵连 到 元 数据 : 包 
含 块 组 的 块 使 用 位 图 ， 块 组 描述 符 的 BH 挂 在 struct transaction s 结构 的 t_buffers 链表 中 。 

(3) 若 发 生 文件 增长 ， 调 用 static int ext4_ext_dirty(…) 将 牵连 到 元 数据 : 包含 struct 
ext4_extent 或 struct ext4 extent idx 的 BH 挂 在 struct transaction s 结构 的 t_buffers 链表 中 。 

(4) 若 发 生 文件 增长 ， 在 write_end(…) 中 将 当前 文件 inode 加 入 的 当前 活动 struct 
transaction_s 结构 的 t_inode_list 列表 。 

(5) 若 发 生 文件 增长 ， 在 write_end(…) 中 调用 int ext4 mark inode dirty(…)， 将 当前 
文件 inode 本 身 当 作 元 数据 挂 入 struct transaction s 结构 的 tbuffers 链表 中 。 

(6) 在 write_end(…) 中 调用 int jbd2_ journal stop(handle t*handle) 结 束 该 handle。 若 当 
前 handle 指出 需要 同步 handle->h_sync， 则 唤醒 kjourmald2， 并 等 待 其 同步 完成 。 否 则 由 
kjournald2 在 合适 的 时 机 同步 。 

/* 

将 需要 修改 BH 的 挂 入 struct transaction s 结构 的 相关 链表 中 ，jh 携带 相关 的 BH 指针 ， 
jlist 指出 了 需要 挂 载 的 目的 链表 ， 对 于 上 文 提 到 的 元 数据 ，1ist 值 为 BJ_Metadata， 对 
于 这 些 元 数据 的 BH，EXT4 仅 使 用 bdev 文件 系统 的 读 ， 并 未 使 用 bdev 文件 系统 的 写 ， 而 将 其 直 
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接 提交 给 JBD2 
*/ 
void _jbd2 journal file buffer(struct journal head *jh, 


transaction t *transaction, int jlist) 


struct journal head **]list = NULL; 
int was dirty = 0; 


// 取 出 携带 的 BH 指针 
struct buffer head *bh = jh2bh (jh); 


// 根 据 j1ist 指出 的 类 型 将 BH 挂 入 对 应 的 链表 

switch (jlist) { 

case BJ None: 
J_ASSERT JH(jh, !jh->b committed data); 
J_ASSERT JH(jh, !jh->b frozen data); 
return; 

case BJ Metadata: 

// 元 数据 需要 挂 入 t_buffers 链表 

transaction->t nr buffers++7 
list = &transaction->t buffers; 
break; 

Case BJ Forget: 


case BJ LogCtl: 


case BJ Reserved: 


// 预 留 操作 


list = &transaction->t _ reserved list; 
break; 


} 

// 挂 入 相关 链表 
_blist add buffer (list, jh); 
jh->b jlist = jlist; 


/* 
将 文件 对 应 inode 加 入 struct transaction s 结构 的 t inode list 列表 


*/ 
int jbd2 journal file inode(handle t *handle, struct jbd2 inode *jinode) 


{ 
// 从 handle 里 找到 当前 transaction 
transaction t *transaction = handle->h transaction; 
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jinode->i _ transaction = transaction; 
// 加 入 当前 transaction 的 t inode 1ist 列表 
list add(gjinode->i list, &transaction->t inode list); 


return 0; 


//kjournald2 对 文件 内 容 页 的 处 理 
static int journal submit data buffers(journal t *journal, 
transaction t *commit transaction) 


struct jbd2 inode *jinode; 
int err, ret = 0; 
struct address_ space *mapping; 


// 保 护 t_inode_1ist 链表 
spin lock(g&journal->j list lock); 
// 依 次 取出 自己 t_inode_1ist 链表 上 的 节点 


list for each entry(jinode, &commit transaction->t inode list, i list) 


// 每 一 个 节点 都 对 应 一 个 文件 page cache 树 
mapping = jinode->i vfs inode->i mapping; 
// 当 前 节点 状态 置 为 “JI_COMMIT _RUNNING， 防 止 竞争 线程 的 间 入 
set bit( JI COMMIT RUNNING, &jinode->i flags); 
spin unlock(&journal->j list lock); 


// 写 当前 文件 节点 
err = journal submit inode data buffers (mapping); 
if (!rzet) 


ret = @rrs 

spin lock(g&journal->] list lock); 

// 清 楚 该 节点 的 _ JI_COMMIT_RUNNING 状态 

clear bit(_ JI COMMIT RUNNING, &jinode->i flags); 

smp mb after clear bit(); 

/ /唤醒 等 待 在 该 节点 ”JI_COMMIT_RUNNING 状态 的 线程 

wake up bit (gjinode->i flags, _ JI COMMIT RUNNING); 
} 
spin unlock(&journal->j] list lock); 


return ret; 


/* 节 点 inode 的 提交 ， 该 函数 的 实现 使 用 内 核 提供 的 inode 写 的 基本 例 程 ， 是 一 个 常规 的 文件 内 
容 写 */ 

static int journal submit inode data buffers (struct address space 
*mapping) 

{ 
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int ret; 
// 写 控制 结构 ， 要 求 做 SYNC 
struct writeback control wbc = { 
-sync _ mode = WB SYNC ALL, 
.nr to write = mapping->nrpages i 
-range start = 0, 
-range end = i size _ read (mapping->host) ， 
}; 
// 写 该 节点 page cache 树 里 的 所 有 脏 页 
ret = generic writepages (mapping，&wbc) 
return ret; 


} 


在 完成 了 文件 内 容 页 的 写 入 之 后 ，kjournald2 才 会 处 理 挂 载 在 自己 t_buffers 上 的 元 数 
据 BH， 这 样 就 保证 了 文件 内 容 页 先 于 元 数据 的 写 入 。 网 上 已 经 有 了 这 方面 的 详细 分 析 ， 
请 大 家 自己 查阅 ， 这 里 不 再 介绍 。 


9.6 Extent tree 


Extent tree 是 EXT4 文件 布局 的 基本 结构 ， 尽 管 EXT4 也 支持 老式 的 间接 块 的 方式 ， 
但 是 间接 块 存在 自身 占用 过 多 磁盘 空间 、 多 大 文件 支持 不 好 等 缺点 ， 所 以 EXT4 的 精髓 之 
一 在 于 其 文件 布局 的 改进 ， 所 以 本 书 只 讨论 Extent tree， 不 再 讨论 间接 块 的 方式 。 


9.6.1 基础 结构 


本 节 描 述 EXT4 文件 系统 的 一 些 基础 结构 。 
struct ext4_extent 记载 一 段 连续 的 物理 块 到 逻辑 块 的 映射 ， 代 码 如 下 : 
struct ext4 extent { 
__ le32 ee block; /* 第 一 个 逻辑 块 */ 
_ lel6 ee len; /* 长 度 */ 
_ lel6 ee start hi; /* 高 16 位 物理 块 地 址 */ 
_ le32 ee start lo; /* 低 32 位 物理 块 地 址 */ 
}; 


这 个 结构 说 明了 ext4 的 文件 大 小 和 文件 系统 的 限制 。 

文件 逻辑 块 地 址 跟 物理 块 地 址 的 关系 类 似 于 处 理 器 的 32 位 虚拟 地 址 映射 40 位 物理 地 
址 的 逻辑 关系 。 文 件 看 到 的 是 逻辑 块 ， 而 在 ARM 32 位 机 器 上 ， 逻辑 块 最 大 是 4 区 ， 所 以 单 
个 文件 限制 是 4GX4K=16T, 物理 块 设备 看 到 的 48 位 索引 地 址 , 文件 块 的 大 小 与 逻辑 块 一 
致 ， 所 以 文件 系统 限制 为 2*X4K。 

struct ext4 extent idx 指 问 struct ext4_extent 表 ， 代 码 如 下 : 
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struct ext4 extent idx { 
_ le32 ei block; /* 对 应 struct ext4 extent 表 的 其 实 逻 辑 块 号 */ 
le32 ei leaf lo; /*struct ext4 extent 表 的 低 32 位 */ 
le16 ei leaf hi; /*struct ext4 extent 表 的 高 16 位 */ 
_ul6 ei unused; 


}; 


struct ext4_extent_header 位 于 struct ext4_ extent 表 或 者 struct ext4_extent idx 表 的 表 头 ， 
也 位 于 节点 inode 结构 。 


struct ext4 extent header { 
_ le16 eh magic; /*probably will support different formats */ 
/*struct ext4 extent 表 或 struct ext4 extent idx 表 的 实际 项 目 数 */ 

e16 eh entries; 

/*struct ext4 extent 表 或 struct ext4 extent idx 表 的 最 大 项 目 数 */ 

_ lel6 eh max; 

/* 表 示 struct ext4_extent 和 struct ext4 extent idx 表 的 层 车 数 ， 如 果 位 于 节点 

inode 且 为 零 ， 则 表示 节点 inode 中 放 的 就 是 struct ext4 extent*/ 

e16 eh depth; 

e32 eh generation; 


9.6.2 ”定位 逻辑 块 的 struct ext4_extent 


从 人 逻辑 块 定位 其 struct ext4_extent 的 过 程 就 是 从 inode 节点 穿 过 struct ext4_extent idx 
表 到 达 struct ext4_extent 对 应 项 的 过 程 。 


/*block 为 需要 映射 的 逻辑 块 号 ，path 为 struct ext4_ ext _path 数组 ， 用 来 记录 从 inode 
节点 开始 ， 需 要 寻找 的 struct ext4 extent 和 struct ext4 extent idx 对 应 项 指针 */ 
struct ext4 ext path * ext4 ext find extent (struct inode *inode, ext4_ 
lblk t block, 


struct ext4 ext path *path) 


struct ext4 extent header *eh; 
struct buffer head *bh; 
short int depth, i, ppos = 0, alloc = 0; 


/* 即 为 (struct ext4 extent header *) EXT4 I(inode)->i data, 在 读 取 EXT4 文件 节 
点 的 时 候 就 把 文件 节点 i_block 位 置 复制 到 i_qata 里 了 ,参见 ext4 inode 的 获取 */ 

eh = ext inode hdr (inode); 
/*i_block 偏 移 0x6 eh_depth， 大 于 零 表示 i block 里 是 struct ext4 extent idx， 等 
于 零 表 示 i_block 里 是 struct ext4 extent*/ 

depth = ext depth (inode); 


/*account possible depth increase */ 
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// 初 始 path 起 始 级 
Path[0] .p hdr = eh; 
path[0] .p bh = NULL; 


i = depth; 
/* 从 inode 开始 逐 级 寻找 */ 
while (i) { 
int need to validate = 0; 


/* 在 当前 struct ext4_extent_idx 表 中 折 半 查找 对 应 项 ，eh_depth 大 于 零 的 ijnode 
也 被 认为 是 一 种 struct ext4 extent idx 表 */ 
ext4 ext binsearch idx(inode, path + ppos, block); 
/*path[ppos] .p_idx 记录 下 struct ext4 extent idx 项 指向 的 下 一 级 表 物 理 块 号 */ 
path[ppos] .p_block 
Path [ppos] .p_depth 
path[ppos] .p_ext = NULL; 
// 读 取 下 一 级 索引 表 
bh = sb getblk(inode->i sb, path[ppos].p_ block); 


ext4 idx pblock(path[ppos] .p_idx); 


i; 


// 找 到 struct ext4 extent idx 表 的 表 头 
eh = ext block hdr (bh); 

// 级 数 递 进 ， 并 记录 表 头 级 存储 表 的 BH 
PPos++7 


path[ppos] .p_ bh = bh; 
path[ppos] .p_hdr = eh; 
时 = 


} 
/* 找 到 了 struct ext4_extent 表 ， 其 位 置 位 于 path[ppos] .p_bh */ 
Path [ppos] .p_depth = i; 
path[ppos] .p_ext = NULL; 
path[ppos] .p_idx = NULL; 


/* 在 struct ext4 extent 表 折 半 查找 对 应 项 */ 


ext4_ext_binsearch (inode，Ppath + ppos, block); 
/*if not an empty leaf */ 


if (path[ppos].p_ext) 
path[ppos] .p block = ext4 ext pblock (path[ppos] .p ext); 


ext4 ext show path(inode, path); 


return path; 
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} 
# 查找 与 struct ext4 extent idx 的 查找 方式 类 似 */ 


/*struct ext4 extent 表 的 折 


static void ext4 ext binsearch(struct inode *inode, 
struct ext4 ext path *path, ext4 lblk t block) 


// 定 位 表 头 


struct ext4 extent header *eh = path->p hdr; 


struct ext4 extent *r, *], *m; 


// 检 查实 际 表 项 
if (eh->eh entries 一 0) { 
return; 


} 


// 表 起 始 项 为 1 

1 = EXT_FIRST EXTENT(eh) + 1; 
// 表 起 始 项 为 

r = EXT LAST EXTENT (eh); 


while (1 <= r) { 
//m 为 当前 中 间 表 项 
m=1+(r-1)/ 2; 
// 以 中 间 表 项 的 逻辑 块 号 作为 折 半 方向 的 依据 
if (block < le32 to cpul(m->ee block)) 


二 
else 
1 = 1 


} 

/* 返 回 最 近 的 起 始 逻 辑 块 号 ， 小 于 当前 待 映射 逻辑 块 的 表 项 。 由 于 其 索引 仅 以 struct 
ext4_extent 起 始 逻 辑 块 号 作为 依据 ， 所 以 待 映射 逻辑 块 可 能 在 返回 的 struct 
ext4_extent 项 以 内 ， 也 能 在 其 长 度 以 外 */ 

path->3p ext = 1 = 1 


} 
9.6.3 ”定位 逻辑 块 左右 侧 的 struct ext4_extent 项 


当 人 逻辑 块 不 在 Extent tree 中 ， 比 如 文件 递增 写 时 越过 了 块 边界 ， 或 者 写 Hole 时 。 这 时 
需要 定位 该 逻辑 块 左右 的 struct ext4_extent 项 。 


/* 定 位 左 struct ext4 _ extent 项 ，path 为 上 一 节 返 回 的 定位 路 径 */ 
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static int ext4 ext search left (struct inode *inode, 
struct ext4 ext path *path, 
ext4 lblk t *]logical, ext4 fsblk t *phys) 


depth = path->p depth; 
*phys = 0; 


/* 定 位 左 struct ext4_extent 项 比较 简单 ， 因 为 上 一 节 返 回 path 的 最 后 一 项 就 记录 了 起 
始 逻 辑 块 小 于 待 映 射 逻辑 块 的 struct ext4_extent 项 。 若 其 长 度 无 法 覆盖 ， 待 映射 的 块 邦 
它 就 是 左 侧 struct ext4_extent 项 */ 

ex = path[depth] .p_ext; 


*logical = le32 to cpul(ex->ee block) + ee len - 1; 
*phys = ext4 ext pblock(ex) + ee len — 1; 


return 0; 


/* 定 位 右 侧 struct ext4_extent 项 ，path 为 上 一 节 返 回 的 定位 路 径 。 定 位 右 侧 struct 
ext4_extent 项 有 两 种 情况 ， 若 上 节 查 找 的 起 始 逻 辑 块 小 于 待 映 射 逻辑 块 的 struct 
ext4_extent 位 于 不 是 struct ext4_extent 表 的 最 后 一 样 ， 那 么 其 后 面 一 项 即 为 所 找 ， 但 是 
如 果 其 为 最 后 一 项 则 需要 逐 级 向 上 索引 ， 再 从 上 级 struct ext4 extent idx 指向 的 struct 
ext4_extent 表 取 第 一 项 */ 
static int ext4 ext search _ right (struct inode *inode, 

struct ext4 ext path *path, 

ext4 lblk t *logical, ext4 fsblk t *phys) 


depth = path->p_depth; 
*phys 0; 


if (depth == 0 && path->p ext == NULL) 
return 0; 


//ex 为 起 始 逻 辑 块 小 于 待 映射 逻辑 块 的 struct ext4 extent 项 
ex = path[depth] .p_ext; 


ee len = ext4 ext get actual len (ex); 


/* 第 一 种 情况 很 简 答 ， 直 接 取 下 一 项 即 可 */ 
IE (ex != EXT LAST EXTENT (path[depth] .p hdr)) { 
// 索 引 到 下 一 项 


ext++2> 
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// 右 侧 逻 辑 块 
*]logical = le32 to cpul(ex->ee block); 
// 右 侧 物 理 块 ， 记 录 下 来 ， 在 块 分 配 时 有 用 
*phys = ext4 ext pblock (ex); 


return 0; 


/* 第 二 种 情况 ， 查 询 上 一 级 ， 上 一 级 若是 最 后 一 项 ， 则 说 明 需 要 的 struct ext4 extent 
项 还 要 从 再 上 一 级 索引 */ 
while (--depth >= 0) { 
ix = path[depth] .p_idx; 
// 判 断 是 否 为 最 后 一 个 struct ext4 extent idx 
if (ix != EXT LAST INDEX (path[depth] .p_hdr)) 
goto got index; 


/* 找 到 最 高 级 struct ext4_extent idx 项 ， 向 下 找 ， 逐 级 读 取 struct ext4_extent 
idx 表 和 定位 struct ext4 extent idx 项 */ 


return 0; 
got index: 


Lt 
// 取 出 最 上 级 struct ext4 extent idx 里 指向 的 物理 块 号 
block = ext4 idx pblock (ix); 
// 逐 级 递 进 
while (++depth < path->p depth) { 
// 读 出 当前 级 的 struct ext4_extent idx 表 
bh = sb bread(inode->i sb, block); 
if (bh == NULL) 
return -EIO; 
// 定 位 表 头 
eh = ext block hdr (bh); 


// 找 第 一 项 ， 往 下 寻找 只 需 取 第 一 项 

ix = EXT FIRST INDEX (eh); 

// 下 一 级 struct ext4 extent idx 表 的 位 置 
block = ext4 idx pblock (ix); 


} 
// 终 于 到 了 struct ext4 extent 表 ， 读 取 
bh = sb _ bread (inode->i_ sb, block); 


// 定 位 表 头 
eh = ext block hdr (bh); 
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// 取 缔 一 项 

ex = EXT FIRST EXTENT (eh); 

// 逻 辑 块 号 

*logical = le32 to cpul(ex->ee block); 
// 物 理 块 号 


*phys = ext4 ext pblock (ex); 


return 0; 


97 块 分 配 


块 分 配 就 是 为 一 个 新 建 的 文件 块 找到 磁盘 上 一 个 对 应 的 存放 位 置 。 
9.7.1 块 组 的 buddy 算法 


EXT4 尽量 在 同一 个 块 组 为 一 个 inode 分 配 物理 块 , 每 一 个 块 组 在 存储 设备 上 都 有 一 个 
bitmap 记录 该 块 组 的 物理 块 使 用 情况 ,该 bitmap 里 每 一 位 对 应 一 个 物理 块 。 为 了 更 好 地 避 
免 碎 片 ，Linux 在 实现 EXT4 的 时 候 ， 使 用 了 与 其 物理 内 存 页 级 分 配 同样 的 伙伴 算法 。 但 
是 不 同 于 页 级 物理 内 存 的 分 配 算 法 的 实现 ，EXT4 通过 层级 的 bitmap 来 实现 对 物理 块 的 分 
割 合 并 。 

第 一 级 bitmap 即 为 块 组 的 物理 块 bitmap， 每 位 记载 一 个 物理 块 是 否 被 使 用 。 然 后 由 
此 向 上 ， 产 生 N 级 bitmap， 每 一 级 的 bitmap size 比 上 一 级 少 一 半 ， 但 是 其 bitmap 里 的 每 

-位 记载 着 六 个 连续 物理 块 是 否 闲 置 , 其 中 从 ”为 一 个 物理 块 大 小 , 其 原因 在 于 一 个 块 组 
正好 用 一 个 物理 块 存放 其 bitmap。 

除了 第 一 级 bitmap 是 直接 从 块 组 中 直接 读 出 来 以 外 ， 其 他 级 别 的 bitmap 都 是 根据 第 
一 级 bitmap 生成 的 。 


/# 为 某 块 组 生成 buddy，group 为 块 组 号 */ 
static noinline for stack int 
ext4 mb load buddy (struct super block *sb, ext4 group t group, 
struct ext4 buddy *e4b) 
{ 
int blocks per page; 
int block; 
int pnum; 
int poff; 
struct page *page; 
int ret; 
struct ext4 group info *grp; 
struct ext4 sb info *sbi = EXT4 SB(sb); 
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/* 内 核准 备 了 一 个 特殊 的 文件 来 存放 所 有 块 组 buddy cache 的 位 图 。 该 文件 特殊 之 处 在 于 内 
核 只 利用 到 了 其 page cache， 其 中 的 page 不 被 dirty， 且 当 作 anon 页 来 处 理 ， 所 以 其 仅 
仅 存 在 内 存 ， 关 机 即 失 */ 


struct inode *inode = sbi->s buddy cache; 


// 计 算 每 一 个 page 对 于 多 少 个 物理 块 

blocks per page = PAGE CACHE SIZE / sb->s blocksize; 
// 索 引 块 描 述 符 

grp = ext4 get group info(sb, group); 


/* 计 算 本 块 组 的 bitmap 在 s_buddy_cache 的 起 始 位 置 。 每 个 块 组 需要 两 个 物理 块 , 一 个 放 
原始 的 bitmap， 一 个 放逐 级 生成 的 bitmap， 所 以 以 物理 块 计算 本 块 组 第 一 级 bitmap 的 起 
始 位 置 为 块 组 号 x2 */ 

block = group * 2; 

/* 每 一 页 放 多 个 块 组 ， 这 里 算出 对 应 以 页 为 单位 起 始 位 置 */ 

pnum = block / blocks per page; 

/* 如 果 块 组 较 小 ， 小 于 2K， 一 页 放置 多 于 2 个 以 上 的 块 组 bitmap， 这 时 需 计算 页 内 偏 移 量 */ 
poff = block $ blocks per page; 


/* 常 规 的 page cache 索引 操作 */ 
page = find get page(inode->i mapping, pnum); 
if (page == NULL || !PageUptodate(page)) { 
/* 第 一 次 访问 需要 创建 页 面 ， 这 里 页 面 分 配属 性 为 GFP_NOFS， 使 得 其 页 面 与 文件 系统 脱 
离 关 系 */ 
page = find or create page (inode->i mapping, pnum, GFP_ NOFS); 
if (page) { 


if (!PageUptodate(page)) { 
/* 页 面 分 配 完毕 要 初始 化 该 页 面 ， 这 里 是 第 一 级 bitmap 需要 从 磁盘 里 读 进 
来 ， 参 见 下 文 分 析 */ 
ret = ext4 mb init cache (page, NULL); 


} 
unlock page (page); 


} 

//bd_bitmap 为 第 一 级 bitmap， 计 算 其 虚拟 地 址 

e4b->bd bitmap page = page; 

e4b->bd bitmap = page address(page) + (poff * sb->s blocksize); 
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/* 提 升 该 页 活跃 度 ， 对 于 无 SWAP 机 制 的 手机 、 媒 入 式 系统 ,这 里 的 操作 没有 实际 意义 ， 这 种 anon 
页 是 不 会 被 shrink 掉 的 */ 


mark _ page _accessed (page); 


/* 本 块 组 其 余 bitmap 在 s_ buddy cache 的 定位 */ 
block++7 
pnum = block / blocks per page; 
poff block $%$ blocks per page; 


// 同 样 在 s_buddy_cache 节点 的 page cache 里 索引 
page = find get page(inode->i mapping, pnum); 
if (page == NULL || !PageUptodate(page)) { 


// 第 一 次 索引 ， 未 遇 ， 分 配 一 个 GFP_NOFS page 
page = find or create page (inode->i mapping, pnum, GFP_ NOFS); 
if (page) { 


if (!PageUptodate(page)) { 
// 初 始 化 其 余 级 别 的 bitmap， 参 见 下 文 
ret = ext4 mb init cache(page, e4b->bd bitmap); 


} 
unlock page (page); 


} 

// 记 录 其 余 级 别 的 bitmap 的 地 址 

e4b->bd_ buddy page = page; 

e4b->bd buddy = page address (page) + (poff * sb->s blocksize); 


mark page accessed (page); 


return 0; 


/* 初 始 化 buddy cache 的 各 级 bitmap， 该 函数 被 调用 两 次 ， 第 一 次 从 磁盘 读 出 块 组 的 bitmap， 
第 二 次 根据 第 一 级 bitmap 生成 其 余 级 别 的 bitmap*/ 


static int ext4 mb init cache(struct page *page, char *incore) 


{ 


inode = page->mapping->host7 


sb = inode->i sb; 
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// 该 文件 系统 共有 多 少 个 块 组 
ngroups ext4 get groups count (sb); 


/* 尽 管 是 特殊 的 inode， 但 是 还 是 有 EXT4 superblock 节点 分 配 函 数 生成 ， 所 以 其 
i_blkbits 与 实际 的 节点 相同 */ 

blocksize = 1 << inode->i blkbits; 

// 每 个 页 对 应 的 物理 块 

blocks per page = PAGE CACHE SIZE / blocksize; 


// 一 个 块 组 要 用 到 两 个 block， 所 以 除 2 

groups_per_ page = blocks per page >> 1; 

if (groups per page == 0) 
groups per page = 1; 


/* 尽 管 小 于 2K 的 情况 是 存在 的 , 但 是 大 部 分 使 用 EXT4 的 手机 、 嵌入 式 系统 的 物理 块 都 是 4K 
了 ， 所 以 一 个 BH 即 可 */ 
if (groups per page > 1) { 

// 小 于 2K 的 情况 


i = sizeof(struct buffer head *) * groups per page; 


bh = kzalloc(i, GFP NOFS); 
} else 
bh = gbhs; 


// 一 个 page 可 能 包含 多 个 block 的 bitmap， 从 第 一 个 对 齐 
first group = page->index * blocks per page / 2; 


/*read all groups the page covers into the cache */ 


for (i = 0; i < groups per page; i++) { 
struct ext4 group desc *desc; 


// 该 块 组 描述 符 


desc = ext4 get group descl(sb, first group + i, NULL); 


/* 从 块 组 描述 符 取出 其 bitmap 所 在 的 物理 块 号 ， 然 后 在 该 文件 系统 所 在 块 设备 对 应 在 


bdev 文件 系统 里 的 节点 中 索引 其 page cache 里 的 Page， 然后 取出 对 应 的 BH， 如 果 没 
有 page， 则 创建 page 再 创建 BH， 这 里 没有 读 */ 
bh[i] sb_getblk(sb, ext4 block bitmap(sb, desc)); 
if (bh[i] == NULL) 
goto out; 
// 该 Bitmap 已 经 update 了 下 一 个 块 组 
if (bitmap uptodate (bh[i])) 


continue; 
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lock buffer (bh[i]); 


ext4 lock group(sb, first group + i); 
// 若 该 块 组 从 来 没有 使 用 过 
(desc->bg flags & cpu to lel6(EXT4 BG BLOCK UNINIT)) { 
// 初 始 化 该 bitmap， 并 写 回 磁盘 
ext4 init block bitmap (sb，bh[il， 
first group + i; dase)s 
// 认 为 bitmap 和 bh 都 update 了 
set_bitmap_uptodate (bh[i]); 
set buffer uptodate (bh[i]); 
ext4 unlock group(sb, first group + i); 
unlock buffer (bh[i]); 
continue; 
} 
ext4 unlock group(sb, first group + i); 
// 如 果 读 出 的 BH 是 update 的 
if (buffer uptodate(bh[i])) { 
/* 更 新 该 bitmap 为 update */ 
set bitmap uptodate (bh[i]); 
unlock buffer (bh[i]); 
continue; 
} 
get_bh (bh[i]); 
/* 到 了 这 里 说 明 该 块 组 从 来 没有 被 读 过 ， 或 者 曾经 被 读 进来 但 是 又 被 shrink 掉 了 ， 这 
时 要 提交 读 操作 */ 
set_ bitmap uptodate (bh[i]); 
bh[i]->b end io = end buffer read sync; 
submit bh (READ, bh[i]); 


/* 对 应 刚才 提交 读 操作 的 情况 ， 这 里 要 等 待 读 操作 完工 */ 
for (i = 0; i < groups per page; i++) 
if (bh[i]) 
wait on buffer (bh[i]); 


/#* 到 了 这 里 , 块 组 bitmap 的 读 操 作 已 经 完成 , 下面 要 生成 buddy cache 其 余 各 级 bitmap*/ 
first block = page->index * blocks per page; 
for (i = 0; i < blocks per page; i++) { 


//data 位 于 buddy cache 节点 的 page cache 

data = page address(page) + (i * blocksize); 
//bitmap 是 位 于 磁盘 bdev 节点 的 page cache 
bitmap = bhlgroup - first group]->b data; 
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// 防 止 其 余 各 级 bitmap 的 块 必 为 计数 块 
《Erstiblock + 13) & 1) 1 


ext4 lock group(sb, group); 
// 首 先 将 各 级 bitmap 都 置 位 
memset (data, Oxff, blocksize); 
/* 生 成 buddy 其 余 各 级 bitmap， 见 下 文 */ 
ext4 mb generate buddy(sb, data, incore, group); 
ext4 unlock group(sb, group); 
incore = NULL; 
} else { 
// 对 于 块 组 bitmap 读 ， 须 将 其 内 容 复制 到 buddy cache 节点 中 
ext4 lock group (sb，group) 
memcpy (data, bitmap, blocksize); 


/* 扫 描 块 组 所 有 预 分 配 块 ,并 将 预 分 配 的 长 度 记录 在 bitmap 里 ,仅仅 改动 budduy 
page cache， 无 块 设备 相关 操作 */ 

ext4 mb generate from pal(lsb, data, group); 

/* 扫 描 块 组 所 有 未 提交 的 自由 块 ， 并 将 预 分 配 的 长 度 记录 在 bitmap 里 ， 仅 仅 改动 
budduy page cache， 无 块 设备 相关 操作 */ 

ext4 mb generate from freelist(sb, data, group); 

ext4 unlock groupl(sb, group); 


incore = data; 


} 
SetPageUptodate (page); 


. 
/*Buddy cache 其 余 各 级 bitmap 的 生成 操作 ，bitmap 为 读 进 来 的 块 组 的 bitmap*/ 
static noinline for stack 
void ext4 mb generate buddy(struct super block *sb, 
void *buddy, void *bitmap, ext4 group t group) 


struct ext4 group info *grp = ext4 get group infol(sb, group); 
ext4 grpblk t max = EXT4 BLOCKS PER GROUP (sb); 

ext4 grpblk t i = 0; 

ext4 grpblk t first; 

ext4 grpblk t len; 

unsigned free = 0; 

unsigned fragments = 0; 


unsigned long long period = get cycles(); 


/* 在 第 一 bitmap 找 出 第 一 空闲 块 */ 
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mb find next zero bit(bitmap, max, 0); 


grp->bb first free = i; 


while (i < max) { 


} 


fragmentst++; 
//first 记录 连续 的 第 一 个 空闲 块 
first = i; 


//i 记录 连续 的 最 后 一 个 空闲 块 
i = mb find next bit(bitmap, max, i); 
//i 与 first 之 间 就 是 空闲 块 的 长 度 
len = i-first; 
free += len; 
if (len > 1) 
// 这 里 开始 构建 buddy cache 其 余 各 级 bitmap 
ext4 mb mark free simple(sb, buddy, first, len, grp); 
else 
grp->bb counters[0]++; 
if (i < max) 
// 继 续 找 下 一 个 空闲 块 


i = mb find next zero bit(bitmap, max, i); 


grp->bb fragments = fragments; 


/* 所 谓 伙伴 算法 就 是 把 整个 长 度 反复 对 折 直 到 为 1， 所 以 每 一 个 空闲 块 的 起 点 都 必须 是 2”*/ 


static void ext4 mb mark free simple(struct super block *sb, 


void *buddy, ext4 grpblk t first, ext4 grpblk t len, 
struct ext4 group info *grp) 


border = 2 << sb->s blocksize bits; 


while (len > 0) { 


// 从 当前 位 置 往 后 能 满足 buddy 分 割 的 长 度 


max = ffs(first | border) - 1; 
/* 计 算 整 个 长 度 为 2 的 几 次 方 */ 
min = fls(len) 一 17 


// 当 前 能 分 割 的 长 度 与 总 长 度 之 间 取 当前 能 分 割 的 长 度 
if (max < min) 
min = max; 


chunk = 1 << min; 


} 
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// 当 前 位 置 对 应 的 可 分 割 长 度 ， 计 算 索引 为 (first >> min) 
if (min > 0) 
mb clear _ bit (first >> min, 
buddy + sbi->s mb offsets [min]) > 


// 还 剩 下 的 长 度 
len -= chunk; 
// 


first += chunk; 


以 一 个 从 块 2612 开始 ， 长 度 为 30156 空闲 为 例 ， 每 次 分 割 的 结构 如 下 : 
当前 起 始 位 置 。 ”当前 分 割 长 度 当前 级 数 

2612 4 2 

2616 8 3 

2624 64 6 

2688 128 7 

2816 256 8 

3072 1024 10 

4096 4096 12 

8192 8192 13 

16384 8192 13 

24576 8192 13 

//buddy cache 其 余 各 级 bitmap 的 地 址 是 在 ext4_mb_init 初始 化 的 

int ext4 mb init(struct super block *sb, int needs_recovery) 


{ 


二 1 

offset = 0; 

max = sb->s blocksize << 2; 

do { 
// 从 i=1 开始 ， 级 数 越 高 表示 连续 空闲 块 越 长 
sbi=>s mb offsets[il = offset; 
sbi->s mb maxs[i] = max; 
// 每 一 级 的 长 度 递减 一 倍 
offset += 1 << (sb->s blocksize bits 一 i); 
max = max >> 1; 
++? 

} while (i <= sb->s blocksize bits + 1); 


2 
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// 查 找 对 应 2^order 长 度 的 位 图 
static void *mb find budqy (struct ext4 buddy *e4b, int order, int *max) 


{ 
char *bb; 


/* 如 果 order 为 0， 则 是 寻找 长 度 为 1 的 连续 块 ， 使 用 的 位 图 是 对 应 块 组 bitmap 的 
bd bitmap */ 
if (order == 0) { 
*max = 1 << (e4b->bd blkbits + 3); 
return EXT4 MB BITMAP (e4b); 
} 
/* 和 否则 以 sbi->s_mb_offsets 数组 为 基 址 ,order 为 索引 去 buddy cache 里 生成 的 bitmap 
地 址 */ 
bb = EXT4 MB BUDDY (e4b) + EXT4 SB(e4b->bd sb)->s mb offsets[order]; 
*max = EXT4_SB(e4b->bd sb)->s mb maxs[order]; 


return bb; 


} 


/* 在 对 应 的 bitmap 里 寻找 block 位 置 处 的 连续 块 ， 这 个 函数 的 前 提 是 已 经 在 最 低 一 级 即 对 应 块 
组 bitmap 里 探测 block 位 置 为 空闲 。 这 里 block 是 物理 块 号 的 组 内 偏 移 量 */ 


static int mb find order for block(struct ext4 buddy *e4b, int block) 
{ 

int order = 1; 

void *bb; 


// 直 接 使 用 buddy cache 中 其 余 各 级 bitmap 
bb = EXT4 MB BUDDY (e4b); 
while (order <= e4b->bd blkbits + 1) { 
// 每 到 一 级 bitmap，block 都 需 除 以 2， 才 能 在 下 一 级 bitmap 里 索引 到 对 应 位 置 
block = block >> 1; 
if (!mb test_bit (block，bb)) { 
/* 该 位 置 置 位 表示 对 应 的 2^order 连续 块 至 少 有 一 半 被 占用 */ 
return order; 
} 
// 该 级 位 置 为 0， 表示 对 应 的 2^orgder 连续 块 空闲 
bb += 1 << (e4b->bd blkbits — order); 
// 探 测 下 一 级 
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Order++7 
} 
return 0; 


} 


9.7.2 ”分配 物理 块 


物理 块 分 配 的 第 一 步 是 找 出 最 理想 的 目标 物理 块 。 对 于 一 个 逻辑 块 ， 其 最 理想 的 物理 


块 是 连续 紧 接 着 自己 上 一 个 逻辑 块 对 应 的 物理 块 ， 这 样 就 能 形成 文件 的 连续 布局 ， 或 者 直 
接 将 在 该 文件 inode 节点 所 在 块 组 位 置 作为 目标 物理 块 。 


// 找 到 逻辑 块 block 最 理想 的 物理 块 ，path 为 上 文 分 析 的 Extent tree 的 索引 结果 
static ext4 fsblk t ext4 ext find goal(struct inode *inode, 


struct ext4 ext path *path, 
ext4 lblk t block) 


if (path) { 
Struct ext4 extent *exs 


depth = path->p_depth; 


/* 直 接 取 最 终 的 struct ext4_extent 项 ， 而 不 是 其 左右 struct ext4_extent 项 ， 
因为 从 最 终 项 才能 找 连续 的 物理 块 */ 


ex = path[depth] .p_ext; 
if (ex) { 


// 最 终 项 的 物理 块 起 始 地 址 


ext4 fsblk t ext pblk = ext4 ext pblock (ex) 
// 最 终 项 的 逻辑 块 起 始 地 址 


ext4 lblk t ext block = le32 to cpul(ex->ee block); 


/* 如 果 该 逻辑 块 大 于 最 终 项 的 逻辑 块 则 取 紧 邻 最 终 项 的 下 一 个 物理 块 ， 这 是 最 常见 情况 
对 应 递增 写 文 件 ， 或 者 取 紧邻 最 终 项 的 前 一 个 物理 块 */ 


if (block > ext block) 


return ext pblk + (block - ext block); 
else 


return ext pblk - (ext block - block); 
} 
} 


/* 没 有 path， 直 接 去 inode 块 组 所 在 位 置 */ 
block group = ei->i block group; 
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// 取 块 组 起 始 块 位 置 
bg start = ext4 group first block no (inode->i sb, block group); 
last block = ext4 blocks count (EXT4 SB(inode->i sb)->s es) - 1; 


// 如 果 是 delay alloc， 直 接 返 回 块 起 始 地 址 
if (test opt (inode->i sb, DELALLOC)) 
return bg start; 


/* 否 则 理想 块 号 被 设置 为 块 组 起 始 物理 块 + 逻辑 块 号 +colour。 其 中 多 辑 块 号 为 文件 内 逻辑 块 
号 ，colour 为 依据 线程 号 散 列 值 */ 
if (bg start + EXT4 BLOCKS PER GROUP (inode->i sb) <= last _ block) 

colour = (current->pid % 16) * 

(EXT4 BLOCKS PER GROUP (inode->i sb) / 16); 

else 

colour = (current->pid % 16) * ((last block - bg start) / 16); 
return bg start + colour + block; 


E 


/* 在 确定 块 分 配 目标 位 置 之 后 ， 要 在 目标 位 置 block 处 寻找 长 度 满足 大 于 或 等 于 ex->fe_len 的 
连续 物理 块 ， 内 核 的 使 用 函数 mb_find_extent 实现 上 述 算法 ， 该 函数 被 内 核 调用 时 参数 order 
都 为 0*/ 


static int mb find extent (struct ext4 buddy *e4b, int order, int block, 
int needed, struct ext4 free extent *ex) 


//order==0， 取 出 最 低 一 级 bitmap， 每 位 对 应 一 个 block 
buddy = mb find buddy (e4b, order, &max); 
/* 测 试 对 应 位 置 是 否 被 占用 ， 如 果 被 占用 ， 意 味 着 block 为 目标 的 分 配 失败 了 */ 
if (mb test bit(block, buddy)) { 
ex->fe len = 0; 


ex->fe start = 0; 


0; 


ex->fe_group 
return 0; 


} 


/*block 位 置 处 空间 ， 再 往 上 寻找 更 大 的 连续 空间 */ 
if (likely(order == 0)) { 
order = mb find order for block(e4b, block); 
/*block 处 对 应 的 2^order 连续 空闲 块 ，block 左 移 order 位 ， 才 能 在 对 应 bitmap 
里 索引 该 连续 块 */ 
block = block >> order; 
// 记 录 下 成 果 


eax->fe. len = 1 < order} 
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ex->fe start = block << order; 


ex->fe group = e4b->bd group; 


/* 若 目标 块 与 连续 块 起 始 地 址 有 差 值 ， 只 取 从 目标 块 开始 的 长 度 */ 
next = next - ex->fe start; 
ex->fe len -= next; 


ex->fe start += next; 


// 如 果 需 要 的 长 度 不 能 够 满足 ， 跳 到 下 一 个 buddy 去 找 更 多 空间 
while (needed > ex->fe len && 
(buddy = mb find buddy(e4b, order, gmax))) { 


if (block + 1 >= max) 
break; 

// 跳 到 当前 找到 的 连续 空闲 块 的 下 一 个 block 

next = (block + 1) * (1 << order) 

// 从 最 低级 的 bitmap 开始 测试 

if (mb test bit(next, EXT4 MB BITMAP(e4b))) 
break; 

// 再 次 沿 着 下 一 个 buddy 的 block 一 级 一 级 往 上 找 连续 空闲 块 

ord = mb _ find order for block(e4b, next); 


// 又 找到 了 一 个 连续 空闲 块 ， 合 并 进来 
order = ord; 
block = next >> order; 
ex->fe len += 1 << orders 

} 

// 这 是 从 block 开始 的 连续 空闲 块 

return ex->fe len; 


. 
ext4 基于 目标 块 的 物理 块 分 配 算法 如 下 : 


/*ac 为 分 配 状态 结构 ， 里 面 记录 了 当前 的 块 分 配 的 状态 ，e4b 则 是 记录 buddy 使 用 的 bitmap 
地 址 */ 
static noinline for _ stack 
int ext4 mb find by goal(struct ext4 allocation context *ac, 
struct ext4 buddy *e4b) 


ext4 group t group = ac->ac g ex.fe group; 
int max; 


int err; 
struct ext4 sb info *sbi = EXT4 SB(ac->ac sb); 


struct ext4 free extent ex; 


/ /首先 检查 分 配 策略 里 是 否 允许 基于 目标 表 来 分 配 
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和 (!(ac->ac flags & EXT4 MB HINT TRY GOAL)) 


return 0; 


// 加 载 puddy 使 用 的 bitmap， 大 多 数 情况 下 都 可 以 命中 page cache 
err = ext4 mb load buddy(ac->ac sb, group, e4b); 
if (err) 


return err; 


// 锁 住 块 组 ， 在 ac 里 已 经 记录 了 目标 的 块 组 

ext4 lock groupl(lac->ac sb, group); 

/*acac->ac_g_ex 是 记录 目标 块 的 分 配 信息 ， ac->ac_g_ex.fe_start 记录 的 是 日 标 块 

号 ，ac->ac_g_ex.fe len 记录 了 需要 分 配 的 长 度 */ 

max = mb find extent(e4b, 0, ac->ac g ex.fe start, 

ac->ac gq_ ex fe len, Sex)s; 

/* 返 回 的 max 指出 从 ac->ac_g_ex.fe_start 开始 有 多 少 个 连续 的 物理 块 ， 下 面 要 检查 max 是 
否 大 于 所 需要 的 长 度 ac->ac_g_ex.fe_len， 如 果 满 足 ， 该 max 个 block 就 被 认为 是 最 佳 分 配 
结果 ，acac->ac_b_ex 记录 着 最 佳 分 配 结果 */ 


if (max >= ac->ac g ex.fe len && ac->ac g ex.fe _ len == sbi->s_stripe) 


ext4 fsblk t start; 
//ext4 新 特性 ，stripe 分 配 
start = ext4 group first block no(lac->ac sb, e4b->bd group) + 


ex.fe start; 


if (do div(start, sbi->s_ stripe) == 0) { 
ac->ac found++; 
ac=>ac b ex = ex? 
ext4 mb use best_found(ac，e4b) 
} 
} else if (max >= ac->ac g ex.fe len) { 
// 记 录 下 最 佳 分 配 结果 
ac->ac foundt++; 
ac->ac b ex = ex; 
/* 这 里 有 两 个 主要 动作 : (1) ac->ac_status 被 置 为 新 状态 : AC_STATUS_FOUND ; (2) 
各 级 buddy 的 bitmap 对 应 为 被 置 位 */ 
ext4 mb use best foundl(ac, e4b); 
} else if (max > 0 && (ac->ac flags & EXT4 MB HINT MERGE)) { 
/* 尽 管 连续 块 不 能 满足 长 度 ， 但 ac 分 配 策 略 允 许 合 并 ， 这 种 情况 也 认为 max 是 最 佳 分 
配 结果 */ 
ac->ac found++; 
ac->ac b ex = ex; 
ext4 mb use best found(ac, e4b); 
} 


ext4 unlock group(ac->ac sb, group); 
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ext4 mb unload buddy(e4b); 


return 0; 


} 
有 了 上 文 的 铺垫 ， 就 可 以 分 析 EXT4 最 近 基 本 块 分 配 动作 ， 代 码 如 下 : 


/* 这 是 EXT4 常规 的 块 分 配 函 数 ， 其 策略 是 首先 基于 目标 块 分 配 算法 在 目标 块 组 里 分 配 所 需 的 物理 
块 。 当 这 个 尝试 无 法 满足 时 再 在 别 的 块 组 里 分 配 物 理 块 */ 
static noinline for stack int 
ext4 mb regular allocator(struct ext4 allocation context *ac) 
{ 

ext4 group t ngroups, group, i; 

int cry 

int err = 0; 

struct ext4 sb info *sbi; 

struct super block *sb; 

struct ext4 buddy ed4b; 


sb = ac->ac_sb; 
sbi = EXT4 SB (sb); 
ngroups = ext4 get groups count (sb); 


/* 首 先 尝试 目标 块 分 配 */ 
err = ext4 mb find by goal(ac，&e4b) 
// 大 多 数 情 况 下 ， 目 标 块 分 配 都 是 有 效 的 ， 直 接 返 回 即 可 
if (err || ac->ac status == AC_STATUS FOUND) 
goto out; 


repeat: 
for (; cr < 4 && ac->ac status == AC STATUS CONTINUE; cr++) { 
ac->ace criteria = ‘ers 
// 从 目标 块 组 开始 
group = ac->ac g ex.fe group; 
// 逐 个 块 组 寻找 


for (i = 0; i < ngroups; groupt++, i++) { 


// 针 对 每 个 块 组 都 要 加 载 buddy cache 各 级 bitmap 
err = ext4 mb load buddy(sb, group, t&e4b); 


// 锁 住 该 块 组 
ext4 lock group(sb, group); 
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// 根 据 需 要 的 长 度 使 用 不 同 的 连续 算法 
GE == 0 
// 简 单 的 直接 扫描 
ext4 mb simple scan groupl(lac, &e4b); 
else if (cr == 1 && sbi->s stripe &é& 
!(ac->ac g ex.fe len $% sbi->s stripe)) 
// 基 于 stripe 的 分 配 
ext4 mb scan aligned(ac, &e4b); 
else 
/* 取 该 块 组 第 一 个 物理 块 ， 从 该 物理 块 开始 寻找 最 符合 连续 块 , 这 与 目标 块 分 
配 非常 类 似 */ 


ext4 mb complex scan grouplac, &e4b); 


ext4 unlock groupl(sb, group); 
ext4 mb unload buddy (&e4b); 
// 找 到 需要 的 最 佳 连续 物理 块 
if (ac->ac status != AC_ STATUS CONTINUE) 
break; 
下 
} 
// 使 用 最 佳 连续 物理 块 
if (ac->ac b ex.fe len > 0 && ac->ac status != RARC_ STATUS FOUND && 
!(ac->ac flags & EXT4 MB HINT FIRST)) { 


// 设 置 buddy cache 的 逐 级 bitmap 
ext4 mb try best foundl(ac, &e4b); 


} 
out: 
return err; 


} 


上 文 描述 的 是 EXT4 物理 块 分 配 的 基本 算法 ， 而 实际 上 EXT4 物理 块 分 配 策略 里 还 有 
个 预 分 配 机 制 。 

首先 每 个 inode 有 个 struct list_head i_prealloc list; 链 表 , 里 面 存放 着 上 文 提 到 每 次 常规 
分 配 用 不 完 的 连续 物理 块 ， 即 最 佳 连续 块 与 实际 需要 的 物理 块 的 差 值 。 

其 次 系统 把 每 次 跨 块 组 分 配 的 用 不 完 的 连续 物理 块 保存 下 来 作为 预 分 配 的 备用 池 ， 车 
在 inode 有 个 struct list_head i_prealloc_list; 链 表 没 有 合适 物理 块 , 则 预 分 配 算法 会 计算 目标 
物理 块 与 这 些 备用 次 里 的 块 组 距离 ， 挑 选 最 近 的 进行 分 配 。 

车 预 分 配 机 制 无 法 满足 要 求 ， 才 会 启动 常规 物理 块 分 配 机 制 ， 且 常规 物理 块 分 配 完成 
后 ， 又 会 把 当 次 用 不 完 物理 块 cache 下 来 给 预 分 配 机 制 使 用 。 


/* 
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Ext4 物理 块 分 配 入 口 函数 
“/ 
ext4 fsblk t ext4 mb new blocks (handle t *handle, 


struct ext4 allocation request *ar, int *errp) 


int freed; 
struct ext4 allocation context *ac = NULL; 


struct ext4 sb info *sbi; 


sb = ar->inode->i sb; 
sbi = EXT4 SB (sb); 


// 分 配 context， 从 头 到 尾 记录 分 配 状 态 的 变化 和 各 个 状态 的 参数 
ac = kmem cache alloc (ext4_ac_cachep，GFP NOFS) 


/* 通 过 struct ext4_allocation request 初始 化 struct ext4_allocation 
context，struct ext4 allocation _ request 里 记录 了 目标 物理 块 号 和 长 度 */ 


*errp = ext4 mb initialize context(ac, ar); 


// 第 一 步 启动 预 分 配 机 制 
if (!ext4 mb use preallocated(ac)) { 
// 预 分 配 机 制 没 有 成 功 ， 转 向 常规 分 配 机 制 
ac->ac op = EXT4 MB HISTORY ALLOC; 
ext4 mb normalize request (ac, ar); 
repeat: 
* 启 用 常规 分 配 机 制 */ 


*errp = ext4 mb regular allocator (ac); 


// 常 规 机 制 成 功 ， 且 分 到 了 多 余 的 物理 块 

if (ac->ac status == AC_STATUS FOUND && 

ac->ac oO ex.fe len < ac->ac b ex.fe len) 
// 将 多 余 的 物理 块 cache 在 预 分 配 机 制 里 
ext4 mb new preallocation(ac); 

日 
if (likely(ac->ac status == AC STRTUS FOUND)) { 

/* 将 块 组 的 bitmap 置 位 ， 这 里 与 buddy cache bitmap 无 关 ， 见 下 文 分 析 */ 


*errp = ext4 mb mark diskspace usedl(ac, handle, reserv blks); 


} else { 
// 分 配 不 成 功 ， 丢 弃 预 分 配 块 


freed = ext4 mb discard preallocations (sb，ac->ac_o_ex.fe len) 
if (freed) 


goto repeat; 
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*errp = —ENOSPC; 


} 


块 组 分 配 的 最 后 一 个 动作 是 置 位 块 组 的 块 使 用 位 图 , 这 是 操作 EXT4 文件 系统 元 数据 ， 
要 启动 日 志 机 制 将 元 数据 写 入 日 志 ， 代 码 如 下 : 


//ac 记录 了 起 始 物理 块 、 长 度 及 块 组 相关 


static noinline for stack int 
ext4 mb mark diskspace used(struct ext4 allocation context *ac, 
handle t *handle, unsigned int reserv blks) 


struct buffer head *bitmap bh = NULL; 
struct ext4 group desc *gdp; 

struct buffer head *gdp bh; 

struct ext4 sb info *sbi; 


sb = ac->ac_sb; 
sbi = EXT4 SB(sb); 


// 读 块 组 的 块 使 用 位 图 
bitmap bh = ext4 read block bitmap(sb, ac->ac b ex.fe _ group) 
if (!bitmap bh) 

goto out err; 


err = ext4 journal get write access (handle, bitmap bh); 


// 取 块 组 描述 符 ， 块 组 描述 符 所 在 bh 为 gdp_bh 
gdp = ext4 get group desc(sb, ac->ac b ex.fe group, &gdp bh); 


err = ext4 journal get write access (handle, gdp bh); 


//ac->ac_b_ex 为 块 组 内 偏 移 量 ， 这 里 计算 实际 物理 块 号 
block = ext4 grp offs to block(sb, &ac->ac b ex); 


len = ac->ac b ex.fe len; 


// 锁 住 块 组 
ext4 lock groupl(sb, ac->ac b ex.fe group); 
// 块 组 bitmap 对 应 位 置 位 ， 这 导致 bitmap_bh 脏 


mb _ set bits(bitmap bh->b data, ac->ac b ex.fe start,ac->ac b ex.fe 
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_len); 


len = ext4 free blks count (sb, gdp) - ac->ac b ex.fe len; 

// 修 改 该 块 组 空闲 物理 块 数目 ， 这 导致 gdp_bh 脏 

ext4 free blks set(sb, gdp, len); 

gdp->bg checksum= ext4 group desc csum(sbi, ac->ac b ex.fe group, gdp); 


ext4 unlock group(sb, ac->ac b ex.fe group); 


/*bitmap_bh 与 gdp 都 是 EXT4 的 metadata, 且 都 被 修改 了 ,状态 都 处 于 脏 (但 是 没 置 脏 标 
志 位 及 提交 给 回 写 机 制 ).EXT4 日 志 体系 需要 将 metadata 写 入 日 志 , 所 以 以 下 要 将 bitmap_bh 
与 gdp 交 给 日 志 系统 处 理 。 关 于 jbd2 分 析 见 相关 章节 */ 

err = ext4 handle dirty metadata (handle, NULL, bitmap bh); 

if (err) 


goto out err; 
err = ext4 handle dirty metadata (handle, NULL, gdp bh); 


9.8 ”逻辑 块 到 物理 块 的 映射 


EXT4 可 以 使 用 传统 的 多 级 间接 块 或 者 使 用 Extent tree 机 制 来 组 织 文件 块 ， 前 者 可 以 
方便 地 兼容 EXT2/3 文件 系统 ， 但 是 效率 太 低 ， 且 元 数据 占用 大 量 空间 ， 所 以 目前 即使 在 
移动 、 嵌 入 式 系 统 EXT4 都 使 用 Extent tree 来 组 织 其 文件 块 。 

逻辑 块 到 物理 块 的 定位 有 以 下 两 种 情况 。 

(1) 已 分 配 物 理 块 的 逻辑 块 的 定位 。 

(2) 逻辑 块 尚未 分 配 物 理 块 ， 需 为 其 分 配 物 理 块 且 构建 Extent tree 各 级 结构 。 

/* 


基于 Extent tree 的 逻辑 块 映 射 物理 块 
*/ 


int ext4 ext map blocks (handle t *handle, struct inode *inode, 
struct ext4 map blocks *map, int flags) 


struct ext4 ext path *path = NULL; 


struct ext4 extent newex, *ex; 


struct ext4 allocation request ar; 


ext4 io end t *io = EXT4 I (inode)->cur aio dio; 
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struct ext4 map blocks punch map; 


/*ext4 有 一 个 简单 但 是 非常 有 效 的 struct ext4 extcache 机 制 ， 每 个 inode 挂 载 了 
-个 struct ext4 ext cache 类 型 的 i cached extent 变量 ， 用 来 记录 最 近 使 用 的 
struct ext4 ext， 每 次 进入 Extent tree 之 间 都 检查 逻辑 块 是 否 落 入 这 个 区 间 */ 
if (ext4 ext in cache (inode，map->m lblk, &newex) && 

((flags & EXT4 GET BLOCKS PUNCH OUT EXT) == 0)) { 


/* 文 件 逻辑 块 号 减 去 struct ext4 ext， 起 始 逻 辑 块 号 再 加 上 struct 
ext4_ext 物理 块 号 即 得 对 应 物理 块 号 */ 
newblock = map->m lblk 

— le32 to cpu(newex.ee block) 

+ ext4 ext pblock (gnewex); 
/* 从 map->m_lblk 往 后 的 物理 块 长 度 */ 
allocated = ext4 ext get actual len(&newex) 一 

(map->m lblk — le32 to cpul(newex.ee block)); 


goto out; 


/* 没 有 落 入 i_cached extent 区 间 ， 进 入 Extent tree， 参 见 上 文 分 析 */ 
path = ext4 ext find extent (inode, map->m lblk, NULL); 


// 取 出 extent tree 的 深度 
depth = ext depth (inode); 


//path 的 最 后 一 项 是 对 应 的 struct ext4 ext 


ex = path[depth] .p_ext; 
if (ex) { 
//struct ext4_ext 起 始 逻辑 块 
ext4 lblk t ee block = le32 to cpul(ex->ee block); 
//struct ext4_ext 起 始 物理 块 号 
ext4 fsblk t ee start = ext4 ext pblock (ex) 
unsigned short ee len; 
//struct ext4_ext 记载 的 长 度 
ee len = ext4 ext get actual len (ex); 
/* 检 查 map->m_ lblk 是 否 落 入 这 个 区 间 ， 对 于 文件 指针 小 于 或 等 于 文件 长 度 的 读 操作 
该 条 件 都 成 立 */ 
if (in range(map->m lblk, ee block, ee len)) { 
// 计 算出 物理 块 号 
newblock = map->m lblk - ee block + ee start; 
/*map->m_1blk 以 后 的 长 度 */ 
allocated = ee len - (map->m lblk - ee block); 
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/* 

到 了 这 里 说 明 是 写 操作 越过 了 文件 结尾 处 

wy 

if ((flags & EXT4 GET BLOCKS CREATE) == 0) { 
/* 
如 果 不 能 创建 新 的 block， 只 有 返回 了 
x 
ext4 ext put gap in cache(inode, path, map->m lblk); 
goto out2; 

} 

/* 

物理 块 分 配 

wy 


/* 找 出 左右 extents 紧邻 的 物理 块 ， 参 见 Extree tree 一 节 */ 
ar.lleft = map->m lblk; 
err = ext4 ext search left (inode, path, é&ar.lleft, &ar.pleft); 
if (err) 
goto out2; 
ar.lright = map->m lblk; 
err = ext4 ext search right (inode, path, &ar.lright, &ar.pright); 
if (err) 
goto out2; 


/* 
若 map->m_len 大 于 EXT_INIT MAX LEN 或 EXT_UNINIT MAX_ LEN， 需要 将 其 与 
EXT_INIT MAX LEN 或 EXT_UNINIT MAX_LEN 对 齐 
A 
if (map->m len > EXT INIT MAX LEN && 

! (flags & EXT4 GET BLOCKS UNINIT EXT)) 

map->m len = EXT INIT MAX LEN; 
else if (map->m len > EXT UNINIT MAX LEN && 

(flags & EXT4 GET BLOCKS UNINIT EXT)) 
map->m len = EXT UNINIT MAX LEN; 


/* 初 始 化 一 个 新 的 extent */ 
newex.ee block = cpu to le32 (map->m lblk); 
newex.ee len = cpu to lel6 (map->m len); 


// 检 查 该 extent 是 否 与 其 他 extent 项 重 半 
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err = ext4 ext check overlap(inode, &newex, path); 
if (err) 

allocated = ext4 ext get actual len (gnewex); 
else 


allocated = map->m len; 


/* 初 始 化 struct ext4 allocation request 结构 */ 
ar.inode = inode; 
/* 找 到 最 相 邻 的 物理 块 */ 
ar.goal = ext4 ext find goal(inode, path, map->m lblk); 
ar.logical = map->m lblk; 
ar.len = allocated; 


//EXT4 物理 块 分 配 ， 参 见 上 一 节 


newblock = ext4 mb new blocks(handle, &ar, &err); 


// 物 理 块 分 配 完毕 ， 将 物理 块 记录 在 struct ext4_extent 
ext4 ext store pblock (gnewex, newblock); 
// 记 录 所 需 长 度 


newex.ee len = cpu to lelé6(ar.len); 


/* 将 struct ext4 extent 插入 到 Extent tree， 该 操作 会 首先 检查 该 struct 
ext4_extent 是 耕 可 以 和 邻近 的 struct ext4_extent 合并 ， 如 果 可 以 合并 ， 直 接 修 
改 紧邻 的 struct ext4_extent 长 度 即 可 。 若 不 能 合并 ， 则 创建 一 个 新 的 struct 
ext4_extent 并 将 其 挂 入 Extent tree。 无 论 如何 都 是 修改 了 metadata， 将 导致 
ext4_ext_dirty 的 调用 ， 从 而 触发 日 志 操作 */ 
err = ext4 ext insert extent (handle, inode, path, 
&newex, flags); 
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Spin_lock 就 好 比 单行 道口 的 红 灯 ， 处 理 器 遇 到 就 得 刹车 ， 随 着 处 理 器 核心 越 来 越 多 ， 
刹车 的 时 机 呈 指 数 增长 的 态势 。 为 了 使 得 系统 顺畅 运行 ， 要 尽 可 能 地 取消 单行 道 ， RCU 就 
好 比 立交 桥 ， 处 理 器 按照 自己 的 道路 顺畅 行驶 ， 不 必 打 扰 别 人 。 


10.1 RCU Tree 


10.1.1 RCU Tree 结构 


为 实现 RCU 结构 的 组 织 ， 内 核 提 供 了 Reutiny 和 Reutree 两 种 结构 ， 前 者 适用 于 处 理 
器 个 数 较 少 的 情况 ，Rcutiny 简单 精 悍 易 于 分 析 ， 本 书 不 做 详细 展开 ，Reutree 用 于 大 型 系 
统 ， 可 管理 数 百 颗 处 理 器 。Rcutree 树 的 叶子 节点 由 struct rcu_data 表示 ， 该 结构 代表 一 个 
处 理 器 ， 中 间 节 点 由 struct rcu_node 表示 ， 根 节点 由 struct rcu_state 表示 。 

RCU 数 层级 的 逻辑 结构 如 下 : 

(1) 如 果 CPU 总 数 小 于 struct rcu_node 的 扇 出 系数 ， 一 层 就 足以 容纳 下 所 有 的 CPU。 

(2) 扇 出 系数 <CPU 总 数 < 扇 出 系数 平方 ， 两 层 的 tree 才能 容纳 下 所 有 的 CPU。 

(3) 扇 出 系数 立方 <CPU 总 数 < 扇 出 系数 4 次 平方 ， 三 层 的 tree 才能 容纳 下 所 有 的 CPU。 

(4) 扇 出 系数 4 次 平方 <CPU 总 数 ， 四 层 的 tree 才能 满足 。 

这 个 层级 结构 在 struct rcu_state 定义 中 得 到 体现 ， 代 码 如 下 : 

struct rcu state { 


// 这 个 数组 存放 所 有 的 struct rcu_node 

struct rcu node node[NUM RCU NODES]; /*Hierarchy*/ 

// 这 个 数组 的 每 一 项 指向 对 应 层 的 第 一 个 struct rcu_node 

struct rcu node *level[NUM RCU LVLS]; /*Hierarchy levels*/ 
// 记 录 了 每 一 层 里 有 几 个 struct rcu node 

u32 levelcnt [MAX RCU LVLS + 1]; /*# nodes in each level*/ 
u8 levelspread[NUM RCU LVLS]; /*kids/node in each level*/ 


每 颗 CPU 对 应 的 管理 结构 struct rcu_data 中 定义 了 4 个 重要 的 RCU 队列 。 


struct rcu data{* 
struct rcu head **nxttail[RCU NEXT SIZE]; 


2} 
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其 中 定义 了 以 下 4 个 RCU 队列 。 

#define RCU DONE TAIL 0 /*Also RCU WAIT head. */ 
#define RCU WAIT TAIL 1 /x*Also RCU NEXT READY head. */ 
#define RCU NEXT READY TAIL2  /*Also RCU NEXT head. */ 
#define RCU NEXT TAIL 3 


其 中 : RCU_DONE TAIL 是 已 经 过 了 grace time 的 RCU 函数 队列 。 
RCU_WAIT_TAIL 是 等 待 当前 的 grace time 的 函数 队列 。 


RCU NEXT READY _TAIL 是 下 一 批 需要 等 待 grace time 的 函数 队列 ， 因 为 RCU_ 


NEXT TAIL 是 随时 会 增加 的 ， 所 以 增加 这 个 队列 。 
RCU NEXT TAILL 是 每 次 新 加 的 函数 被 放 入 这 个 队列 。 


10.1.2 ”RCU Tree 的 构建 


RCU Tree 的 初始 化 是 根据 处 理 器 核心 数 , 将 上 一 节 的 层级 结构 实体 化 。 这 是 在 系统 启 


动 之 初 就 需要 完成 的 工作 。 
static void _init rcu init one(struct rcu state *rsp) 


| 


/* 首 先 把 struct rcu_node *level[] 中 每 个 元 素 指向 对 应 的 每 一 层 的 第 一 个 struct 


rcu node*/ 
for (i = 1; i < NUM RCU LVLS; i++) 
rsp->level[i] = rsp->level[i - 1] + rsp->levelcnt[i - 1]; 


// 该 函数 计算 出 每 一 层 的 struct rcu_node 对 应 多 少 颗 CPU 


rcu init levelspread(rsp); 
// 下 面 从 底 往 上 ， 初 始 化 整个 RCU tree 的 每 个 struct rcu_node 结 点 


for (i = NUM RCU LVLS - 1; i >= 0; i--) { 
/ /首先 找到 该 层 每 个 struct rcu_node 下 对 应 多 少 颗 CPU 
cpustride *= rsp->levelspread[i]; 
// 找 到 这 一 层 的 第 一 个 struct rcu node 
rnp = rsp->level[il]; 
for (j = 0; j < rsp->levelcnt([i]; j++, rnp++) { 


raw_ spin lock init(g&rnp->lock); 


rnp->gpnum = 0; 
rnp->qsmask = 0; 


rnp->qsmaskinit = 0; 


/* 该 struct rcu_node 对 应 索引 值 最 小 的 CPU， 每 一 层 的 cpustride 值 都 


不 同 */ 
rnp->grplo = j * cpustride; 
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// 该 struct rcu_node 对 应 索引 值 最 大 的 CPU 
rnp->grphi = (a + 1) * cpustride - 1; 
if (rnp->grphi >= NR CPUS) 
rnp->grphi = NR CPUS - 1; 
if (i == 0) { 
// 到 了 顶层 


rnp->grpnum = 07 


} else { 
/* 该 struct rcu node 在 上 一 层 struct rcu node 结 点 中 索引 ，j 实际 上 是 
该 层 的 索引 ，rsp->levelspread[i - 1] 是 上 一 层 struct rcu_node 结 点 管 
理 多 少 个 本 层 结 点 ， 通 过 取 余 即 可 */ 

rnp->grpnum = j % rsp->levelspread[i — 1]; 
// 对 应 的 mask 位 

rnp->grpmask = 1UL << rnp->grpnum; 

// 记 录 下 父 节 点 是 什么 

rnp->parent = rsp->level[i — 1] + 

j / rsp->levelspread[i — 1]; 

} 
// 记 录 下 该 struct rcu_node 所 在 层 数 
rnp->level = i; 
INIT_ LIST HEAD(&rnp->blocked tasks[0]); 


// 接 驶 每 个 CPU 的 rcu_sched_data 到 对 应 的 struct rcu node 


#define RCU_INIT FLAVOR(rsp, rcu data) \ 
de. \ 


// 初 始 化 struct rcu state 

rcu init one(rsp); \ 

// 最 底层 的 第 一 个 结 点 

rnp = (rsp)->level [NUM RCU LVLS - 1]; \ 

j=0;\ 

for each possible_cpu(i) { \ 

//i 是 CPU 的 索引 ，j 是 struct rcu node 结 点 的 索引 
if (i > rnp[j] .grphi) \ 

jt AN 

// 将 每 个 CPU 的 rcu_sched data 的 mynode 指向 对 应 的 结 点 
per cpul(rcu data, i).mynode = grnp[j]; \ 
// 在 struct rcu state 里 记录 下 该 CPU 
(rsp)->rda[li] = &per_cpu(rcu data, i); \ 
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rcu boot init percpu datal(li, rsp); \ 
}\ 
} while (0) 


// 进 一 步 初 始 化 每 个 CPU 的 rcu sched data 结构 
static void init 
rcu boot init percpu data (int cpu, struct rcu state *rsp) 
{ 
unsigned long flags; 
int 1 
// 找 到 处 理 器 对 应 的 数据 
struct rcu data *rdp = rsp->rda[lcpu]; 


// 取 出 struct rcu_node 树 的 根 结 点 


struct rcu node *rnp = rcu get root (rsp); 


raw_spin lock irqsave(&rnp->lock, flags); 

// 算 出 该 CPU 在 其 对 应 struct rcu_node 里 的 mask 

rdp->grpmask = 1UL << (cpu - rdp->mynode->grplo); 

rdp->nxtlist = NULL; 

// 初 始 化 该 CPU 的 RCU 队列 

for (i = 0; i < RCU NEXT SIZE; i++) 
rdp->nxttail[i] = &rdp->nxtlist; 


raw_spin unlock irqrestore (grnp->lock, flags); 


} 


以 上 只 是 静态 初始 CPU 及 struct rcu_node 树 的 静态 关系 。 事 实 上 这 时 候 该 CPU 还 没 
有 被 激活 ， 在 该 CPU 被 激活 后 调用 函数 static void _cpuinit rcu_online_cpu(int cpu)， 进 一 
步 完 成 初始 化 。 


10.2 Grace Period 


10.2.1 Grace Period 的 检测 


每 个 处 理 器 都 经 过 至 少 一 次 quiescent state， 称 为 grace period。 处 理 器 处 于 quiescent 
state 时 机 如 下 : 

(1) 进 io 

(2) 用 户 态 ， 线 程 处 在 用 户 态 。 

(3) 处 理 器 运行 idle 线程 或 进入 没有 tick 的 状态 idle。 

每 颗 处 理 器 在 自己 的 RCU_SOFTIRQ 中 , 若 自己 经 过 了 一 次 quiescent state， 则 需要 向 
系统 报告 ， 代 码 如 下 : 
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static void 
rcu check quiescent statel(struct rcu state *rsp, struct rcu data *rdp) 


{ 
/* 在 当前 处 理 器 等 待 quiescent state 或 RCU_SOFTIRQ 之 前 ， 系 统 启动 了 新 一 轮 grace 
period 的 等 待 。 该 函数 将 当前 处 理 器 对 应 结构 struct rcu_data 的 成 员 变 量 gpnum 更 新 
为 新 一 轮 的 grace period 号 , 且 将 qs pending 置 1*/ 
if (check for new grace periodl(rsp, rdp)) 


return; 


/* 新 一 轮 grace period 被 启动 ，qs_pending 被 置 1 */ 
if (!rdp->qs pending) 


return; 
/* 
在 经 过 quiescent state 时 该 值 被 置 1 
4 
if (!rdp->passed quiesc) 
return; 
/* 
向 上 一 级 即 struct rcu_node 结构 汇报 ， 当 前 处 理 器 已 经 经 过 一 个 quiescent state 
状态 
wy 


rcu report qs _rdp(rdp->cpu, rsp, rdp, rdp->passed quiesc completed); 


/* 最 底层 struct rcu_node 结构 要 检查 是 否 自己 属 下 所 有 处 理 器 都 经 过 quiescent state 状 
态 ， 如 果 该 条 件 成 立 ， 则 逐 级 向 上 层 struct rcu_node 结构 汇报 */ 
static void 
FrCu_Treport_qs_rdp (int cpu, struct rcu_state *rsp, struct rcu data *rdp, long 
lastcomp) 
{ 

unsigned long flags; 

unsigned long mask; 

struct rcu node *rnp; 


// 当 前 处 理 器 直属 一 级 的 struct rcu_node 结构 


rnp = rdp->mynode; 

raw_spin lock irqsave(&rnp->lock, flags); 

/* 检 查 当前 处 理 器 经 过 quiescent state 号 是 否 是 该 struct rcu_node 结构 正在 检测 的 
*/ 

if (lastcomp != rnp->completed) { 


/* 
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这 种 情况 发 生 在 刚刚 有 别 的 处 理 器 抢先 启动 了 新 一 轮 grace period 的 等 待 。 这 时 当 
前 处 理 经 过 quiescent state 当 作 无 效 ， 等 待 新 一 轮 grace period 

uf 

rdp->passed quiesc = 0; /*try again later! */ 


raw_ spin unlock irqrestore (grnp->lock, flags); 
return; 


} 
/*grpmask 记录 了 当前 处 理 器 在 其 直属 struct rcu_node 结构 里 的 对 应 位 */ 


mask = rdp->grpmask; 


if ((rnp->qsmask & mask) == 0) { 
raw_ spin unlock irqrestore(&rnp->lock, flags); 
} else { 


/* 当 前 处 理 器 在 直属 struct rcu_node 结构 ， 认 可 当前 处 理 经 过 quiescent state 有 效 */ 
rdp->qs_pending = 0; 


/* 
当前 处 理 器 挂 载 的 RCU 递 进 ， 但 并 不 意味 着 这 些 RCU 可 以 执行 了 ， 因 为 全 部 处 理 器 状 
态 还 没有 全 部 检查 完 
至 

rdp->nxttail [RCU NEXT READY TAIL] = rdp->nxttail[RCU NEXT TAIL]; 


// 向 中 间 级 struct rcu_node 结构 报告 
rcu report qs rnp(mask, rsp, rnp, flags); /*rlses rnp->lock */ 


/* 中 间 层 向 struct rcu_node 结构 的 quiescent state 状态 检测 ， 若 当前 struct rcu_node 
结构 所 管辖 的 所 有 处 理 器 的 quiescent state 状态 有 效 意 味 着 可 以 向 上 一 级 struct rcu_node 
结构 汇报 */ 


static void rcu report qs_rnp(unsigned long mask, struct rcu state *rsp, 
struct rcu node *rnp, unsigned long flags) 


_ releases (rnp->lock) 
struct rcu node *rnp c; 


/* 逐 级 向 struct rcu_node 结构 汇报 */ 
For tre) A 


/* 清 除 当前 层 对 应 的 上 一 层 struct rcu_node 对 应 位 */ 
rnp->qsmask &= ~mask; 
if (rnp->qsmask != 0 || rcu preempt blocked readers_cgp (rnp)) { 
/* 当 前 层 对 应 的 上 一 层 struct rcu_node 对 应 位 已 经 被 清除 ， 这 种 情况 发 生 在 同 级， 
struct rcu node 所 管辖 的 处 理 器 中 还 有 未 达到 quiescent state 状态 */ 
raw_ spin unlock irqrestore(g&rnp->lock, flags); 


return; 
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} 


mask = rnp->grpmask; 


/* 同 级 struct rcu_node 所 管辖 的 处 理 器 中 均 达 到 quiescent state 状态 ， 需 向 上 
层 报告 */ 
rnp c = rnp; 
// 当 前 struct rcu_node 结构 的 父 节 点 
rnp = rnp->parent; 
raw_ spin lock irqsave(&rnp->lock, flags); 


/* 
顶层 struct rcu_node 所 管辖 处 理 器 均 达到 quiescent state 状态 , 需 向 根 节点 struct 
rcu_state 报告 
wf 
rcu report qs rspl(rsp, flags); /*releases rnp->lock. */ 


//struct rcu state 控制 着 全 局 grace period 的 更 新 
static void rcu report qs rsp(struct rcu state *rsp, unsigned long flags) 


_releases(rcu get root(rsp)->lock) 


// 更 新 完成 GP 号 

rsp->completed = rsp->gpnum; 
rsp->signaled = RCU_ GP_IDLE; 
// 重 新 启动 一 个 新 的 GP 号 


rcu start gpl(rsp, flags); /*releases root node's rnp->lock*/ 


10.2.2 ”重新 启动 新 一 轮 Grace Period 


启动 新 一 轮 Grace Period 的 关键 是 要 将 整个 RCU tree 重 置 ， 这 样 每 个 处 理 器 到 达 后 才 
能 顺利 向 上 汇报 。 
/* 启 动 新 一 轮 的 GP*/ 


static void 
rcu start gp(struct rcu state *rsp, unsigned long flags) 


_ releases(rcu get root (rsp)->lock) 


/*GP 号 更 新 */ 
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rsp->gpnumt+t+; 

rsp->signaled = RCU GP INIT; /*Hold off force quiescent state. */ 
rsp->jiffies force qs = jiffies + RCU JIFFIES TILL FORCE QS; 

// 记 录 启 动 时 间 

record gp stall check time (rsp); 


/* 对 于 只 有 一 层 struct rcu_node 结构 的 情况 */ 
if (NUM RCU NODES == 1) { 
rcu preempt check blocked tasks (rnp); 
// 把 唯一 个 struct rcu_node 更 新 至 初始 状态 即 可 
rnp->qsmask = rnp->qsmaskinit; 
//GP 号 更 新 
rnp->gpnum = rsp->gpnum; 
// 完 成 GP 号 更 新 
rnp->completed = rsp->completed; 
rsp->signaled = RCU SIGNAL INIT; /*force quiescent state OK*/ 
/*GP 号 更 新 且 当 前 处 理 器 对 应 struct rcu_node 结构 的 completed 被 更 新 ， 更 新 
处 理 器 的 nxttail 数组 指针 */ 
rcu start gp per cpul(rsp, rnp, rdp); 
raw_spin unlock irqrestore (grnp->lock, flags); 
return; 


raw_spin unlock (grnp->lock); /*leave irqs disabled*/ 


/* 针 对 多 层 struct rcu_node 结构 的 情况 ， 把 每 一 层 struct rcu_node 结构 都 重新 更 新 
为 初始 值 */ 


rcu for each node breadth first(rsp, rnp) { 
raw_spin lock(grnp->lock); /*irqs already disabled*/ 


// 更 新 qmask 初始 值 
rnp->qsmask = rnp->qsmaskinit; 
// 更 新 GP 号 


rnp->gpnum = rsp->gpnum; 
// 更 新 completed 号 
rnp->completed = rsp->completed; 
/* 对 与 当前 处 理 同 属 第 一 层 struct rcu_node 的 处 理 器 更 新 其 nxttail 数组 指针 */ 
if (rnp == rdp->mynode) 
rcu start gp per cpulrsp, rnp, rdp); 


raw_spin unlock (grnp->lock); /*irqs remain disabled*/ 


第 10 章 RCU 237 


10.3 ”RCU 函数 的 执行 


(1) 在 每 颗 处 理 器 Tick 的 时 候 ， 会 检查 当前 处 理 器 上 是 否 有 RCU pending， 如 果 成 立 
将 导致 Raise RCU_SOFTIRQ。 

(2) RCU_SOFTIRQ 软 中 断 中 会 调用 static void _rcu process_callbacks(struct reu_state 
*rSp, struct reu_data *rdp) 函 数 来 检查 。 


static void _rcu process callbacks(struct rcu state *rsp, struct rcu data 
*rdp) 
' 


/* 针 对 本 处 理 器 ， 检 查 自己 的 RCU_WAIT_TAIL 队列 等 待 的 grace time 是 否 到 期 ， 如 果 已 
到 期 则 将 各 队列 依次 向 前 调整 */ 

rcu process gp _ end(rsp, rdp); 

// 从 这 里 逐 层 检查 各 CPU 


rcu check quiescent state(rsp, rdp); 


// 当 前 处 理 器 的 RCU_DONE_TAIL 队列 不 空 ， 说 明 有 过 了 GP 的 RCU 函数 需要 运行 
if (cpu_has_callbacks_ready to _invoke (rdp) ) 
invoke rcu callbacks (rsp, rdp); 

和 
// 该 函数 软 中 断 环境 中 执行 
static void invoke rcu callbacks(struct rcu state *rsp, struct rcu data 
*rdp) 
{ 


// 因 为 处 在 软 中 断 环境 ， 只 有 有 限 级 较 高 的 RCU 函数 才 放 在 这 里 执行 

if (likely(!'rsp->boost)) { 
rcu do batchl(rsp, rdp); 
return; 

} 

/* 对 于 普通 的 RCU 函 数 在 内 核 线程 rcu_cpu_kthread 中 执行 ,这 里 唤醒 rcu_cpu_kthread 

内 核 线程 */ 

invoke rcu callbacks kthread 0 全 顾 


} 
(3) rcu_cpu_kthread 内 核 线 程 的 主体 如 下 : 


static void rcu kthread do work(void) 


{ 
// 该 函数 依次 取出 挂 在 struct rcu_data 结构 的 struct rcu_head 队列 ， 依 次 执行 


rcu do batch(grcu sched state, &_ get cpu varl(rcu sched data)); 
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这 是 本 书 分 析 的 唯一 一 个 驱动 子 系统 。 本 书 原 计 划 不 想 涉及 驱动 , 但 这 是 笔者 的 心 结 ， 
因为 笔者 觉得 只 有 Block 层 通 了 以 后 ， 内 核 横向 架构 才 算 是 得 到 了 贯通 的 分 析 : 虚拟 内 存 、 
VFS、 文 件 系统 、BLOCK 和 块 设备 驱动 。 


11.1 MMC Driver 


MMC Driver 有 以 下 三 个 方面 。 

(1) MMC Host 即 MMC 控制 器 ， 与 具体 芯片 有 关 ， 在 host 目录 下 可 以 发 现 不 同 SOC 
的 MMC 控制 器 。 这 里 涉及 具体 芯片 操作 ， 对 于 架构 分 析 意义 不 大 ， 本 文 略 去 MMC 控制 
器 层面 的 分 析 。 

(2) MMC 协议 , 即 运行 在 MMC 控制 器 上 的 协议 ,一 个 MMC 控制 器 可 能 支持 SDIO、 
SD、MMC 等 不 同 设备 。 针 对 不 同 设备 在 Core 目录 中 有 着 不 同 实 现 。 

(3) 块 设备 ， 即 内 核 意 义 的 块 设备 ， 这 里 将 底层 的 MMC 设备 抽象 层 上 文 提 到 抽象 块 
设备 ， 并 接 驶 到 内 核 块 设备 层 。 


11.1.1 MMC 协议 层 


MMC 控制 器 上 电 后 , MMC 协议 层 要 做 第 一 件 事 是 依次 通过 MMC 控制 器 检测 是 否 有 
满足 自己 的 协议 规范 的 设备 。 


//MMC 控制 器 上 电 后 ， 驱 动 调用 该 函数 检测 MMC 设备 


static int mmc rescan try freq(struct mmc host *host, unsigned fred) 


{ 


/*SDIO 设备 检测 */ 

if (!mmc attach sdio(host)) 
return 0; 

/*SD 设备 检测 */ 

if (!mmc attach sd(host)) 
return 0; 

/*EMMC 设备 检测 */ 

if (!mmc attach mmc (host)) 


return 0; 
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mmc power off (host) 


return -EIO; 


/* 
以 EMMC 为 例 进一步 分 析 ， 该 函数 关于 EMMC 协议 操作 的 部 分 略 去 ， 着 重 分 析 其 与 EMMC 设备 的 检 
测 与 注册 
本 
int mmc attach mmc (struct mmc host *host) 
下 
/* 
操作 emmc host 检测 emmc 设备 ， 若 检测 到 emmc 设备 ， 则 生成 struct mmc_card 并 挂 
到 struct mmc host 下 
二 


err = mmc init card(host, host->ocr, NULL); 


/* 将 struct mmc_card 注册 到 驱动 框架 ， 将 触发 标准 的 device 和 driver 匹配 */ 


err = mmc add card(host->card); 


11.1.2 ”MMC 块 设备 


在 struct mmc_card 注册 时 将 匹配 其 对 应 的 EMMC 块 设备 驱动 函数 ， 其 实现 位 于 
driver/mmc/card/block.c， 提 供 的 驱动 列表 如 下 : 


static struct mmc driver mmc driver = { 


.drv ={ 

.name = "mmcblk", 
}, 
-Probe = mmc blk probe, 
remove = mmc blk remove, 
.suspend = mmc_ blk suspend, 
.resume = mmc blk resume, 


}; 
通过 mmc_bus_type 匹配 名 为 mmcblkdevice 


// 探 测 函 数 是 MMC 驱动 的 骨架 
static int mmc blk Probe (struct mmc card *card) 


{ 
struct mmc blk data *md, *part md; 


/* 创 建 struct gendisk 和 struct request _queue 关键 函数 ，MMC 块 设备 的 基础 设施 
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都 是 这 里 构建 ， 下 文 详细 分 析 */ 
md = mmc blk alloc(card); 
if (IS ERR(md)) 
return PTR ERR (md); 
// 启 动 host 操作 ， 设 置 扇 区 大 小 


err mmc blk set blksize (md, card); 
if (err) 
goto out; 


/* 对 于 EMMC 卡 ， 其 头 部 有 两 个 boot partition， 这 里 为 其 创建 struct gendisk， 尽 管 


在 emmc spec 是 partition 的 概念 ， 在 Linux 里 将 其 当 作 独 立 的 块 设备 来 对 盘 ， 其 主 设备 
号 为 0xb3， 次 设备 号 分 别 从 0x20，0x40 开始 */ 
if (mmc blk alloc parts(card, md)) 

goto out; 


mmc set drvdatal(card, md); 


// 硬 件 错误 修补 
mmc_fixup_device (card，blk fixups) 
/* 向 block 层 注册 */ 
if (mmc add disk (md)) 
goto out; 


/* 将 boot partition 对 应 上 独立 的 块 设备 向 block 注册 */ 
list for each entry(part md, gmd->part, part) { 
if (mmc add disk(part md)) 
goto out; 


//MMC 驱动 的 基础 设施 是 这 里 创建 的 
static struct mmc blk data *mmc blk alloc req(struct mmc card *card, 
struct device *parent, 
SOGtor t siney 
bool default ro, 
const char *subname) 


struct mmc blk data *md; 


int devidx, ret; 


//struct mmc blk data 对 应 一 张 eMMC 或 者 SD 卡 ，MMC 驱动 block 层 使 用 


md = kzalloc(sizeof (struct mmc blk data), GFP KERNEL); 
if (!'md) { 
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ret = -ENOMEM; 


goto out; 


// 分 配 内 核 bock 层 使 用 struct gendisk 结构 ，perdev_minors 是 允许 的 分 区 数 
md->disk = alloc disk(perdev minors); 
//struct mmc_queue 的 创建 和 关键 动作 将 后 面 详细 分 析 


ret = mmc init queue(g&md->queue, card, &md->lock, subname); 


if (ret) 
goto err putdisk; 


// 初 始 化 struct gendisk 结构 的 详细 信息 
md->queue.issue fn = mmc blk issue rq; 


md->queue.data = md; 


md->disk->major = MMC BLOCK MAJOR; 
md->disk->first minor = devidx * perdev minors; 
//disk 设备 文件 操作 函数 

md->disk->fops = &mmc bdops; 


md->disk->private data = md; 

/*struct request_queue 由 MMC 驱动 提供 ， 意 味 着 MMC block 设备 有 自己 的 struct 
backing_dev_info 结构 */ 

md->disk->queue = md->queue.queue; 

md->disk->driverfs dev = parent; 

set disk rol(md->disk, md->read only || default ro); 


md->disk->flags = GENHD FL EXT DEVT; 


// 设 置 block 层 扇 区 大 小 
blk queue logical _ block size(md->queue.queue, 512); 
// 设 置 block 层 设 备 容量 大 小 


set_ capacity(md->disk, size); 


int mmc init queue(struct mmc queue *mq, struct mmc card *card, 
spinlock t *]ock, const char *subname) 


mq->card = card; 
/* 创 建 struct request queue 其 request_ fn proc 函数 为 mmc request。 struct 
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backing dev_info 初始 化 在 这 里 完成 */ 


mq->queue = blk init queue (mmc request, lock); 


//struct request _ queue 的 prep rq fn; 函 数 为 mmc prep request 
blk queue prep rq(mq->queue, mmc prep request); 


/ /负责 将 block 提交 的 操作 转发 给 mmc host 
mq->thread = kthread run(mmc queue thread, mq, "mmcqd/%d%s", 


host->index, subname ? subname : ""); 


11.2 ”开源 手机 U8836D (MT6577 ) 分 区 的 实现 


这 里 的 分 区 ， 不 是 操作 系统 的 分 区 概念 ， 也 和 架构 没有 太 大 关系 ， 关 心 系统 架构 的 读 
者 可 以 直接 略 过 此 节 。 

本 节 描 述 的 是 EMMC 上 的 Android 镜像 的 布局 ， 对 于 MTK 系列 Android 手机 来 讲 
hancking 与 ROM 的 烧 写 有 着 较 大 的 实用 意义 。 

从 华为 开源 的 代码 里 可 以 看 出 , 内 核 是 通过 读 取 写 在 EMMC user 分 区 里 的 分 区 表 来 获 
得 系统 分 区 信息 的 ,而 分 区 的 信息 位 置 是 固定 的 ,从 1024 开始, 起 始 位 置 签名 为 0x50547631 
的 扇 区 ; 或 者 从 1024+ 2048 开始 ， 起 始 位 置 签 名 为 0x4D505431 的 扇 区 。 这 个 位 置 应 该 是 
MTK 的 烧 写 软件 与 bootm 约定 好 的 ， 因 为 从 log 里 看 preloader 也 在 里 面 ， 而 bootm 必 取 
preloader。 也 许 mtk 烧 写 软件 将 preloader 同时 写 入 EMMC 的 boot 分 区 ， 但 是 这 样 又 限制 
的 EMMC 版 本 ， 为 了 支持 庞大 的 EMMC 供应 商 列表 ，MTK 应 该 不 会 这 样 做 。 


static int load exist part tab emmc(u8 * buf) 


{ 
int reval = ERR NO EXIST; 


Ee 

int len=0; 

// 读 入 内 存 的 分 区 表 的 指针 

char *buf p; 

// 从 这 个 位 置 开始 找 分 magic 为 0x50547631 的 分 区 表 
loff t pt start = 1024; 

// 从 这 个 位 置 开 始 找 分 magic 为 0x4D505431 的 分 区 表 
loff t mpt start = pt start + 2048; 

loff t pt addr = 0; 
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int pn per pmt = 0; 
// 分 区 表 大 小 为 2K， 分 区 表 的 最 后 也 有 签名 
int per pmt size = 2048; 


pt resident32 *lastest part32; 

int blk size = 512; 

// 每 次 读 取 的 长 度 

int read size = 16*1024;//8192;//4096; 
char *page buf = NULL; 

char *backup buf = NULL; 


// 读 取信 息 暂 存在 page_buf 


page buf = kmalloc(read size, GFP KERNEL); 


/* 从 1024 开始 ， 找 起 始 位 置 签名 为 0x50547631 的 扇 区 */ 
for (i=0;i<CFG EMMC PMT SIZE/read size;i++) 


buf p = page buf; 
// 启 动 emmc 读 


reval = eMMC rw x(pt start + i*read size, (u32*) page 


buf, 0,0, read size,1,USER); 


// 逐 个 扇 区 找 签 名 

for (j=0;j<read size/blk size;j++){ 
// 条 件 成 立 ， 则 表示 分 区 表 的 签名 找到 
if(is valid pt(buf p)){ 


// 当 次 读 取 的 内 容 没 有 把 分 区 表 全 部 读 进来 
if((read size-j*blk size) < per pmt size){ 
len = read size- j*blk size; 
// 把 已 经 读 进 来 的 分 区 表 放 入 backup_buf 
memcpy (backup buf, gbuf pl[PT SIG SIZE],len-PT_ 


SIG SIZE); 


// 再 次 启动 EMMC 读 ， 把 剩 下 分 区 表 读 进 来 
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reval =eMMC rw x(pt start+ (i+1)*read size, (u32*) 


page buf,0,0,per pmt size,1,USER); 


/# 检 查分 区 表 的 尾部 签名 ， 如 果 仍然 存在 签名 ， 说 明 分 区 表 还 有 另 


外 一 部 分 ， 长 度 为 per_pmt size*/ 


if(is valid pt(g&page buf[per pmt size-4-len]))t{ 


// 记 录 下 分 区 表 的 位 置 


pt addr = pt start + i*read sizet+j*blk size; 


pi.pt has space = 1; 
reval=DM ERR OK; 
goto find; 
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jelsei{ 
// 这 种 情况 是 ， 一 次 即 把 分 区 表 全 都 读 进来 ， 检 查 尾 部 签名 
if(is _ valid pt(&buf p[per pmt size-PT SIG SIZE]) ){ 


// 记 录 分 区 表 另 一 个 部 分 的 位 置 
pt addr = pt _ start + i*read size+j*blk size; 
1; 


pi.pt has space = 
reval=DM ERR OK; 


goto find; 


} 
break; 
} 
buf p += blk size; 
} 
} 
// 从 1024 开始 的 位 置 没 有 搜索 到 分 区 表 
if(i == CFG EMMC PMT SIZE/read _ size) 
{ 
pi.pt has space = 0; 
/* 从 mpt_start 位 置 搜索 分 区 表 , 方法 同上 参见 上 文 , 大 多 数 情况 下 不 会 走 到 这 里 */ 
for (i=0;i<CFG EMMC PMT SIZE/read size;i++){ 


3 


// 没 有 找到 分 区 表 的 情况 
if(i == CFG EMMC PMT SIZE/read size){ 


reval = ERR NO EXIST; 
} 
goto end; 
// 分 区 表 已 被 读 到 内 存 中 backup_buf[] ， 做 进一步 处 理 
find: 
// 如 果 还 有 另 一 部 分 ， 那 么 在 当前 这 个 per_pmt size 的 尾部 有 标准 位 指示 
pi.pt next = (backup_buf[per_pmt_size-11]>>4)&OxOF7 
pi.sequencenumber 


backup buf[per pmt size-12]; 


/ /继续 读 入 另 一 部 分 分 区 表 ， 这 种 情况 很 少见 

if(pi.pt next == 0x1){ 

//pt_adqdr 已 经 记录 了 分 区 另 一 部 分 在 EMMC 上 的 位 置 ， 启 动 读 取 操 作 
reval = eMMC rw x(pt addr+iper pmt size, (u32*)page buf,0, 
0,per pmt size,1,USER); 
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// 再 次 检查 第 二 部 分 分 区 表 的 签名 
if((is valid pt(pPage buf)sgis _ valid pt(&page _ buf[per_ pmt size-4]))| 
1 (is_validqd mpt (page buf) ssgis _ valid mpt (gpage buf[per pmt size-4]))){ 
pt next = 1; 
// 把 读 进来 分 区 表 信息 整理 到 backup_buf 
if (emmc size<0x100000000ULL){ 
memcpy (&backup buf[pn per pmt*sizeof (pt resident32)],&gpage buf[4], 
per pmt size-8); 
}elsef{ 
memcpy (&backup buf[pn per pmt*sizeof (pt resident)],é&page buf[4],per_ 


pmt size-8); 


}elsef{ 
printk("can not find next pt, error\n"); 
} 


} 
if (emmc size<0x100000000ULL){ //32bit 


//backup_buf 信息 倒 腾 到 lastest_part32 

memcpy (lastest part32,backup buf, PART MAX COUNT*sizeof (pt_ 

resident32)); 

// 逐 项 整理 lastest_part32 信息 待 内 核 使 用 

for (i=0;i<PART MAX COUNT;i++) 

{ 

if(lastest part32[i].name[0]!=0x00){ 

memcpy (lastest part[i] .name,lastest part32[i].name,MAX_ 
PARTITION NAME LEN); 
lastest part[i].size= lastest part32[i].size; 
lastest part[i].offset= lastest part32[i].offset; 
lastest part[i] .mask flags= lastest part32[i] 
-mask flags; 


}elsef{ 
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12.1 Conf 


在 做 ARM BSP 移植 的 时 候 经 常会 弄 错 内 核 模 块 的 依赖 关系 。 作 为 工具 性 质 的 最 后 一 
章 内 核 部 分 ， 本 节 分 析 内 核 配置 系统 的 原理 ， 以 供 参 考 。 


12.1.1 ”Kconfig 元 素 


Kconfig 最 基本 的 元 素 是 字符 串 , 由 struct symbol 表示 , 是 组 成 其 他 元 素 的 最 基本 单元 。 
Kconfig 的 结构 就 是 menu 的 层级 结构 ， 由 三 种 类 型 的 menu 的 层级 构成 。 

(1) 第 一 级 是 menu， 其 基本 结构 是 menu*…endmenu。 

在 arch/arm/kconfig 文件 中 ， 有 个 处 理 器 架构 选择 就 是 menu: 


menu "System Type" 

config MMU 
bool "MMU-based Paged Memory Management Support" 
default y 


choice 
prompt "ARM system type" 
endmenu 


该 menu 的 菜单 项 由 config MMU、choice 构成 。 
(2) 第 二 级 是 Choice, 其 基本 结构 是 choice … endchoice, 例 如 :同样 在 arch/arm/kconfig 
文件 中 ， 对 SOC 架构 选择 就 是 Choice。 


choice 
prompt "ARM system type" 
default ARCH VERSATILE 


endchoice 


config ARCH SOCFPGA 
bool "Altera SOCFPGA family" 
select ARCH WANT OPTIONAL GPIOLIB 
select ARM AMBA 
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config ARCH REALVIEW 
bool "ARM Ltd. RealView family" 


Select 


select 


RARM AMBA 
CLKDEV_LOOKUP 


config ARCH VERSATILE 
bool "ARM Ltd. Versatile family" 


select 


endchoice 


ARM AMBA 


该 menu 的 菜单 项 由 不 同 的 config XXXX 构成 。 
(3) 第 三 级 是 config， 这 是 最 低级 的 菜单 ， 不 包含 菜单 项 ， 但 是 有 相应 的 属性 ， 如 : 


config ARCH _S5PV210 
bool "Samsung S5PV210/S5PC110" 


select 
select 
select 
select 
select 
select 


help 


CPU_V7 

ARCH_SPARSEMEM ENABLE 
ARCH_HAS_HOLES MEMORYMODEL 
GENERIC_GPIO 

HAVE_CLK 

CLKDEV_LOOKUP 


Samsung S5PV210/S5PC110 series based systems 


12.1.2 ”Kconfig 分 析 


Kconfig 的 分 析 很 简单 ， 如 下 : 

(1) 遇 到 任何 非 菜单 元 素 都 是 该 current_menu 的 属性 。 

(2) 遇 到 菜单 元 素 时 , 生成 并 进入 新 菜单 ,因为 任何 时 候 都 有 一 个 当前 menu， 由 struct 
menu *current_menu 表示 。 上 一 级 菜单 记录 为 当前 菜单 的 成 员 变 量 struct menu *parent;: 
menu->parent = current menu:。 


(3) 当前 menu 结束 ，struct menu *current_menu 恢复 为 本 级 菜单 的 父母 菜单 。 


enum yytokentype { 
T MAINMENU = 258, 
T MENU = 259, 
T_ENDMENU = 260, 
T_SOURCE = 261, 
T_CHOICE = 262, 
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Choice 的 处 理 : Choice 其 实 就 是 一 种 menu， 遇 到 Choice 时 处 理 与 menu 处 理 相 似 。 


case 51: 
‘ 
/* 为 这 个 Choice 名 字 生 成 struct symbol 结构 */ 
struct Symbol *sym = sym lookup((yyvsp[(2) - (3)] .string), SYMBOL_ 
CHOICE); 
sym->flags |= SYMBOL AUTO; 
/* 为 这 个 choice 生成 struct menu 结构 */ 


menu add entry(sym); 
} 


遇 到 endchoice， 代 码 如 下 : 


case 53: 


{ 
if (zconf endtoken((yyvsp[(1) - (1)].id), T_CHOICE, T_ENDCHOICE)) { 
/* 把 当前 menu 恢复 到 上 一 级 menu*/ 


menu_ end menu(); 


12.2 内 核 调试 


内 核 调试 手段 是 一 个 广 受 争议 的 话题 。 笔 者 认为 ， 内 核 调 试 的 唯一 有 效 手段 是 运行 时 
的 内 核 纯 内 存 操作 的 LOG。 

对 于 内 核 调试 ， 常 用 的 调试 应 用 程序 的 一 些 手 段 如 断 点 、 单 步 跟踪 、 修 改 内 存 等 做 法 
一 律 无 效 。 这 些 调试 手段 有 两 种 实现 : 一 种 是 像 KGBD 这 种 靠 在 内 核 代码 里 添加 代码 ， 青 
从 一 个 外 部 机 器 来 控制 ， 另 外 一 种 是 用 在 线 仿真 器 如 trace32、DS-5 (realview) 来 控制 处 
理 器 ， 再 用 台 机 器 运行 调试 UI、 控 制 在 线 仿真 器 。 这 些 手段 虽然 可 以 解决 一 些 直 观 易 发 现 
的 bug， 但 是 这 些 调试 手段 自身 却 破坏 了 内 核 原 有 的 状态 。 

如 内 核 断 点 企图 让 内 核 停 下 来 以 观察 内 核 状 态 ， 但 是 内 核实 际 运 行 的 时 候 怎 么 可 能 停 
下 来 ? 当前 线程 不 停 向 前 走 ， 各 种 中 断 思 里 哺 啦 进来 ， 触 发 各 种 服务 例 程 ， 当 前 线程 不 断 
被 打 断 、 被 抢占 、 被 恢复 …… 这 才 是 真正 的 内 核 运行 状态 。 如 果 忽 略 这 些 状 况 ， 强 行 钳 住 
处 理 器 ， 或 者 甚至 靠 添加 调试 代码 来 造成 内 核 停止 、 单 步 了 的 现象 都 是 假象 ， 是 实际 运行 
时 不 可 能 存在 的 。 

内 核 不 是 被 驯服 的 应 用 线程 ， 内 核 调试 唯一 有 效 手段 就 是 在 内 核 代 码 里 手工 加 入 修改 
掉 设备 操作 的 printk， 再 想法 输出 内 核 运行 信息 ， 然 后 通过 分 析 这 些 运 行 信息 来 调试 代码 。 

未 经 修改 的 printk 并 不 是 在 内 核 任何 地 方 都 能 用 ，printk 本 身 要 操作 console， 需 要 操 
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作 semaphore 而 且 会 引入 中 断 。 所 以 需要 将 printk 的 console 操作 去 掉 ， 让 printk 不 去 操作 
硬件 ， 不 去 down semaphore。 这 样 printk 就 是 一 个 纯 操 作 内 存 的 函数 ， 就 能 够 在 内 核 的 任 
何 一 个 地 方 使 用 了 。 

其 实 这 样 还 会 对 内 核 造成 影响 ， 就 是 printk 也 是 需要 花 时 间 的 ， 处 理 器 要 把 printk 跑 
掉 。 在 较 弱 的 处 理 器 上 尤其 要 注意 , 在 ARM7 上 调试 的 时 候 笔者 曾 发 现 , 有 时 驱动 里 printk 
加 的 多 了 ， 外 设 来 不 及 响应 ， 最 后 发 现 是 跑 printk 的 时 间 太 长 了 。 现 在 的 处 理 器 CA8/CA9 
跑 printk 己 经 非常 快 了 ， 不 过 随 着 Linux 内 核 复杂 度 的 飙升 ， 任 何 时 间 都 不 能 忽视 处 理 器 
跑 内 核 代 码 花 费 的 时 间 对 系统 的 影响 。 

说 到 这 里 ， 还 有 个 问题 没有 解决 ，pintk 把 内 核 信 息 打 印 到 内 存 了 ， 但 是 怎么 才能 把 这 
些 内 存 里 的 信息 捞 出 来 呢 ? 方法 有 很 多 ， 笔 者 最 喜欢 以 下 两 种 方式 。 

(1) 通过 在 线 仿真 器 把 LOGBUF 里 的 内 存 荡 出 来 ， 市 面 上 的 在 线 仿真 器 中 ， 不 论 是 
独步 天 下 的 trace32、DS-5 还 是 山寨 货 ， 所 有 的 仿真 器 都 有 下 载 内 存 功能 ， 只 是 下 载 速度 
快慢 的 问题 。 仿 真 器 调试 内 核 适合 比较 生猛 的 情况 ， 比 如 把 Linux 移植 到 全 新 处 理 器 架构 
下 ， 前 几 年 笔者 有 个 项 目 把 Linux 2.6 移植 到 某 DSP 上 ， 刚 开始 Arch 下 什么 都 还 没有 ， 只 
能 靠 仿真 器 把 内 核 甩 下 去 ， 运 行 一 定时 间 再 把 LOGBUF 荡 出 来 。 但 是 这 种 方式 有 个 弊端 ， 
就 是 需要 开 一 个 比较 大 的 LOGBUF， 因 为 要 在 最 后 一 次 性 把 内 存 荡 出 来 ， 一 个 4M 的 
LOGBUF 还 经 常 溢出 ， 荡 一 次 内 存 往往 要 七 八 分 钟 。 

(2) 第 二 种 方式 适合 在 一 个 基本 稳定 但 又 需要 追踪 比较 罕见 的 BUG 的 时 候 ， 往 往 需 
要 荡 出 来 数 十 M 的 LOG 信息 , 这 样 需要 既 能 pintk 到 内 存 ， 又 能 同时 往外 输出 。 这 种 情况 
下 ， 笔 者 通常 的 作法 如 下 。 

@ 保持 pintk 不 变 , 在 适当 时 机 、 适 当地 方 执行 printk, 这 时 printk 会 把 整个 LOGBUF 

@ 再 做 个 函数 senix_printk， 该 函数 基于 printk 改造 ， 把 printk 操作 console 相关 地 方 
去 掉 ， 该 函数 依旧 输出 到 LOGBUF， 因 为 有 logbuf lock 锁 存 在 ， 所 以 不 会 打扰 原始 ptinrk 
的 输出 。 

这 样 方式 的 前 提 是 内 核 基本 OK， 串 口 能 输出 ，printk 的 时 机 要 在 LOGBUF 满 之 前 得 
到 执行 ， 否 则 会 溢出 。 详 细 分 析 见 下 文 。 


12.2.1 senix_printk 


本 节 分 析 常 用 的 内 核 调试 方法 ， 曾 述 思路 供 大 家 参考 、 指 正 。 
/*senix Printk 与 printk 参数 定义 完全 一 样 ， 且 在 printk.h 里 暴露 给 内 核 使 用 */ 
asmlinkage int senix printk(const char *fmt，…) 
{ 
va list args; 


int r; 


// 获 取 参 数 


va start (args, fmt); 
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// 实 际 工作 换 成 senix_vprintk 
r= senix vprintk(fmt, args); 


va end(args); 


return r; 


//senix _vprintk 从 vprintk 改造 而 来 
asmlinkage int senix vprintk(const char *fmt, va list args) 
{ 
int printed len = 0; 
int current log level = default message loglevel; 
unsigned long flags; 
int this_ cpu; 
char *p; 
size t plen; 
char special; 


/* 把 当前 处 理 器 状态 寄存 器 值 存 入 flags， 并 将 状态 寄存 器 中 断 位 置 位 ， 禁 止 中 断 。 这 里 关中 断 是 
为 了 防止 在 处 理 器 执行 下 面 代码 的 时 候 ， 当 前 处 理 器 上 的 中 断 窜 进 来 ， 导 致 当前 处 理 器 跑 到 这 里 。 
printk 通过 spin_ lock(&logbuf_ lock) ;来 保证 LOGBUF 的 访问 ，spin_lock(&logbuf 
lock) 就 像 一 扇 门 ， 在 多 颗 处 理 器 狭路相逢 的 时 候 挡 得 住 别 的 处 理 器 ， 而 在 自己 通过 狭 路 的 时 候 
spin_unlock(&logbuf lock) 再 打开 这 扇 门 ， 让 别 的 处 理 器 通过 狭 路 。 但 是 当前 处 理 器 处 在 狭 
路 的 时 候 ， 处 理 器 被 抢占 ， 又 重新 进入 狭 路 之 前 ， 等 待 狭 路 之 门 打开 ， 但 是 这 时 却 没有 人 能 够 打开 狭 路 
之 门 了 。 唯 一 能 够 抢占 狭 路 上 的 CPU 只 有 中 断 ， 所 以 这 里 关 掉 中 断 ， 防 止 这 种 极端 事件 产生 */ 

raw_local irq save (flags); 

// 当 前 CPU 号 

this_cpu = smp_processor id(); 


/* 如 果 printk_cpu 是 当前 CPU， 那 说 明 printk 被 不 正常 重 入 了 ， 这 与 抢占 不 同 ， 这 是 处 理 器 
跑 乱 了 */ 
if (unlikely(printk cpu == this cpu)) { 


/* 进 入 到 这 里 有 两 种 可 能 : (1) 在 pintk 是 内 核 崩 溃 ， 而 内 核 崩溃 前 又 要 把 信息 打出 去 ， 
如 果 崩 溃 很 频繁 ， 比 如 新 处 理 器 移植 的 初期 ， 就 得 用 仿真 器 了 ，console 并 不 把 全 部 信息 
输出 出 去 : (2) printk 时 又 递归 调用 了 printk，printk 代码 不 止 是 大 家 在 书 里 看 到 
的 这 些 ， 在 console_unlock() :里 有 一 大 坨 驱动 相关 的 代码 ， 里 面 有 可 能 调用 printks/ 


if (!oops in progress) { 
recursion bug = 1; 
goto out restore irqgs; 

} 

zap_locks(); 
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lockdep off(); 
// 狭 路 之 门 ， 关闭 

spin lock(&logbuf lock); 
//printk cpu 为 当前 cpu 
printk cpu = this CPU; 


printed len += vscnprintf (printk buf + printed len, 
sizeof (printk buf) - printed len, fmt, args); 


/*printk_buf 已 经 被 放 入 要 输出 的 格式 及 参数 信息 */ 


P = printk buf; 


/* 正 常情 况 下 ，printk_buf 的 前 三 位 P[0] ,P[1]，P[2] 为 <L>， 工 是 内 核定 义 的 
KERN_ EMERG -KERN DEBUG, KERN _ DEFAULT, KERN CONT, 这 里 current log leve 
记录 工 的 信息 ， 如 果 工 为 KERN_DEFAULT，KERN_CON，speical 记录 其 信息 */ 

plen = log prefix(p, &current log level, &special); 


if (plen) { 
P += plen; 


switch (special) { 
case 'c': /*KERN_CON 表示 继续 前 面 一 行 输出 */ 
plen = 0; 
break; /*break， 不 产生 以 后 */ 
case 'd': /*KERN_DEFAULT， 表 示 新 起 一 行 */ 
plen = 0; 
default: 
if (!new text line) { 
// 只 要 没有 指定 KERN_CON， 就 是 新 一 行 ， 这 里 输出 到 LOGBUF 中 
emit log char('\n'); 
new text line = 1; 


} 
/* 依 次 处 理 剩 下 的 输出 信息 ， 将 其 复制 到 LOGBUF */ 


for (; *p; P++) { 
// 处 理 每 一 行 
if (new text line) { 


new text line = 0; 


/* 时 间 戳 是 在 这 里 取得 */ 
if (Printk time) { 
/*Add the current time stamp */ 
char tbuf[50], *tp; 


unsigned tlen; 


232 


拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 


unsigned long long t; 

unsigned long nanosec rem; 
/* 这 里 直接 从 硬件 计时 器 取 值 ， 但 是 取得 时 间 跟 打印 信息 的 时 间 有 个 偏差 ， 而 且 
从 调用 printk 到 走 到 关中 断 之 前 是 有 可 能 被 线程 或 者 中 断 抢占 ,如 果 要 获得 精度 
较 高 的 时 间 需 要 自己 在 代码 里 取 */ 

t = cpu clock(printk cpu); 


for (tp = tbuf; tp < tbuf + tlen; tp++) 
// 把 时 间 送 到 LOGBUG 

emit log char(*tp); 

printed len += tlen; 


} 


if (!*p) 
break; 
}// 每 一 行 开 头 的 处 理 器 到 此 结束 
// 把 这 一 行 的 信息 输出 到 LOGBUF 
emit log char(*p); 
// 遇 到 \n 时 另 起 一 行 
if (Bp = "Mar) 
new text line = 1; 
} 
// 关 键 的 改动 在 这 里 ， 删 掉 console 相关 操作 
//if (console trylock for printk(this cpu)) 
// console unlock(); 
// 当 前 处 理 器 离开 了 pintk，printk_cpu 被 置 为 UINT_MAX 
printk cpu = UINT MAX; 
// 狭 路 之 门 开启 
spin_unlock(&logbuf lock); 


lockdep_on(); 


out restore irqs: 


/* 恢 复 中 断 状 态 ， 这 里 不 是 打开 中 断 ， 而 是 把 进入 printk 之 前 的 处 理 器 状态 寄存 器 恢复 */ 


raw_local irq _ restore (flags) 


return printed len; 


12.2.2 LOG_BUF 


LOG_BUF 是 用 来 放置 printk log 信息 的 地 方 ， 有 两 种 实现 方式 。 
一 种 直接 在 内 核 里 定义 一 个 大 数组 : 


static char _log buf[ LOG BUF LEN]; 
static char *log buf = log buf; 
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一 种 方式 是 在 内 核 参数 里 指定 其 大 小 :log_buf len, 内 核 分 析 到 该 参数 用 static unsigned 
long_initdata new_log_buf len; 记 录 其 大 小 ， 然 后 在 内 核 启 动 时 调用 void _init setup_ log_ 
buflint early) 来 显示 的 创建 LOG_BUF。 


void _init setup log buf(int early) 
{ 
// 如 果 启动 参数 指定 LOG_BUF 的 大 小 ， 那 么 内 核 会 在 new_1og_buf_ len 记录 这 个 长 度 
if (!new log buf len) 
return; 
/* 内 核 动 态 的 创建 LOG_BUF 的 基础 是 内 存 分 配 ， 正 常 的 内 存 分 配 体系 是 buddy system， 这 是 
- 串 串 4K 整 数 倍 的 内 存 块 ; 在 这 之 前 的 是 bootmem, 这 是 一 片 位 图 ,每 位 代表 一 页 ;而 在 bootmem 
是 从 bootloader 里 收集 的 内 存 分 布 信息 。 正 常情 况 下 在 bootmem 后 再 动态 创建 LOG_BUF， 
但 是 有 些 系 统 上 比较 着 急 ， 要 尽快 分 配 比 较 大 的 LOG_BUF， 所 以 这 就 是 early 参数 的 意义 */ 
if (early) { 
unsigned long mem; 
//bootmem 还 没 建立 起 来 ， 只 好 从 memblock 分 配 内 存 
mem = memblock alloc(new_ log buf len, PAGE SIZE); 
if (mem == MEMBLOCK ERROR) 


return; 
// 算 出 分 配 出 来 的 内 存 对 于 的 虚拟 地 址 
new_ log buf = _ val(mem); 
} else { 


/* 从 bootmem 里 分 配 内 存 比较 从 容 了 。new_1og_buf 直接 返回 的 就 是 虚拟 地 址 */ 


new_log buf = alloc bootmem nopanic(new log buf len); 


/* 分 配 好 了 新 的 LOG_BUF， 下 面 要 进行 LOG_BUF 的 切换 ， 关 中 断 、 锁 住 logbuf_lock， 只 
有 CPU0 在 跑 ， 这 里 只 可 能 有 中 断 来 打扰 ， 只 关中 断 即 可 ， 不 需要 锁 住 logbuf_lock*/ 
spin lock irqsave(&logbuf lock, flags); 
/*10g_buf 数组 是 内 核 静态 定义 的 ， 不 管 动不动 态 分 配 ， 它 就 在 那里 ， 现 在 要 把 静态 数组 的 
log_buf 里 的 数据 倒 到 新 分 配 的 LoOG_BUF 里 ， 并 且 把 相关 指针 切换 过 来 */ 
log buf len = new log buf len; 
//1og_buf 指向 新 分 配 内 存 
log buf = new log buf; 
new log buf len = 0; 
free = _ LOG BUF LEN - log end; 
//con start，1og_start 是 LOG_BUF 的 两 个 机 制 ， 见 下 文 
offset = start = min(con start, log start); 
dest idx = 0; 
// 把 log_buf 里 的 数据 倒 到 新 分 配 的 LOG_BUF，LOG_BUF 已 指向 新 BUF 
while (start != log end) { 
unsigned log idx mask = start & (_ LOG BUF LEN — 1); 


log bufl[dest idx] = log buf[log idx mask]; 
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Start+t+s 
dest idx++; 
} 
/* 静 态 数组 的 1og_buf 里 的 数据 倒 进来 了 ， 等 于 LOG_BUF 内 容 增加 ， 自 然 要 把 指针 往 后 推 


- 推 */ 
log start -= offset; 
con start 一 = offset; 
log end -= offset; 


// 解 锁 ， 恢 复 先前 的 中 断 状态 
spin unlock irqrestore(&logbuf lock, flags); 
} 


LOG_BUF 的 运作 主要 是 靠 以 下 三 个 指针 来 实现 的 。 
(1) log_start: Linux 系统 上 sysklogd 从 这 里 提取 log。 
(2) con_start: 控制 台 从 这 里 输出 log 信息 。 

(3) log_end: log 信息 的 结束 地 址 。 


// 该 函数 是 向 LOG_BUF 写 LOG 信息 的 唯一 入 口 
static void emit_1og_char (char c) 
//1og_end 是 LOG 的 最 后 地 址 ， 也 是 第 一 个 空闲 内 存 ， 写 入 
LOG BUF(log end) = c; 
//1og_end 指针 向 后 推移 
log_ end++; 
// 循 环 BUF, 若 log_end 追 F 了 1og_start，log_start 向 后 串 
if (log end - log start > log buf len) 
log_start = log end - log buf len; 
// 循 环 BUF， 若 1og_end 追 上 了 con_start，con_start 向 后 串 
if (log end - con start > log buf len) 
con_start = log end - log buf len; 
if (logged chars < log buf len) 
logged charst++; 
} 


在 每 次 调用 printk 时 ， 都 会 调用 void console_unlock(void)。 该 函数 是 LOG_BUF 信息 
输出 的 关键 动作 。 在 进入 该 函数 之 前 ， 需 要 拿 到 console semaphore。 


void console unlock (void) 


{ 


/* 该 函数 主要 对 console 操作 ， 如 果 console 不 可 用 ， 也 就 没有 可 以 继续 下 去 的 意义 了 ， 释 放 
semaphore， 返 回 */ 
有 (console suspended) { 
up (&console_sem) 


return; 
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console may schedule = 0; 
Eee 
// 关 中 断 ， 锁 1ogbuf_ lock， 这 里 用 得 很 恰当 
spin lock irqsave(&logbuf lock, flags); 
// 先 做 件 好 事 ， 看 看 是 否 叫 醒 sysklogd 
wake klogd |= log _ start - log end; 
/* 检 查 自己 是 否 有 工作 要 做 ， 如 果 con_start == 1og_end 说 明 没有 需要 console 


输出 的 信息 */ 
if (con start == log end) 
break; /*Nothing to print */ 


// 有 活 要 干 ， 要 把 从 con_start 到 log_end 的 10g 信息 从 console 里 送出 去 
_con start = con start; 
_log end = log end; 


con start = log end; /*Flush */ 
/* 解 开 1ogbuf_1ock， 把 别 的 处 理 器 放 进来 ， 这 时 con_start == 1og_end 已 成 立 ， 
不 担心 别 的 处 理 器 来 里 折腾 */ 


spin unlock(&logbuf lock); 
// 调 用 console 驱动 把 1og 信息 送出 去 
call console drivers( con start, log end); 
/* 直 到 这 里 才 开 中 断 ， 这 就 能 保证 如 果 console 驱动 不 开 中 断 ， 可 以 得 到 个 干净 的 输出 */ 
local irq restore (flags); 
} 
console locked = 0; 
// 释 放 控制 台 
up(l&console sem); 
// 这 里 对 应 上 面 的 break 情况 
spin unlock irqrestore (glogbuf lock, flags); 
/*sysklogd 一 般 通 过 syslog 趴 在 1og_wait 上 , 叫 醒 sysklogd。 一 个 系统 应 该 尽量 干净 ， 
在 嵌入 式 系统 或 者 Android， 这 个 机 制 最 好 不 要 用 */ 
if (wake klogd) 
wake up klogd(); 
} 


Printk 表面 上 是 个 简单 的 打印 函数 , 但 是 其 下 是 较 复 杂 的 console 驱动 的 体系 ， 而 更 关 
键 的 是 printk 被 用 在 内 核 各 种 情况 下 ， 这 使 得 复杂 度 被 急剧 放大 。 笔 者 最 近 遇 到 的 一 个 教 
训 是 : SMP 系统 下 ，CPU1 的 启动 过 程 会 丢失 LOG_BUF 的 内 容 。 原 因 如 下 : printk 调用 
控制 台 驱 动 经 过 如 下 函数 。 


static void _call console drivers (unsigned start，unsigned end) 


for_each_console (Con) { 


if (conenable && con->write gg& 


// 检 查 当前 CPU 是 否 在 线 
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(cpu online(smp processor id()) || 

// 恰 巧 该 平台 下 的 console flags 是 CON_PRINTBUFFER 
(con->flags & CON ANYTIME) ) ) 

con->write (con, &LOG BUF (start), end - start); 


该 函数 在 确认 当前 CPU 在 线 后 才 会 进入 console 的 写 函 数 ， 在 处 理 器 online 被 置 位 之 
前 调用 printk， 将 出 现 LOG_BUF 的 丢失 ， 无 论 是 通过 senix_printk 写 入 还 是 通过 printk 的 
LOG 信息 都 被 冲 掉 。 为 从 处 理 器 启动 到 set_cpu online(cpu，true); 这 段 时 间 ， 
cpu_online(smp_processor_id() 都 为 否 ， 但 是 这 时 控制 台 的 con_start 都 被 指向 了 log_end， 
于 是 LOG_BUF 信息 被 丢失 。 


下 篇 “Dalvik 与 Android 用 户 态 源 
码 分 析 


Android 用 户 态 == Dalvik 虚拟 机 +Binder+ 功 能 类 库 。 
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作为 系统 中 最 简单 也 是 最 复杂 的 系统 ， 内 存 管理 似乎 是 一 个 永远 也 说 不 完 的 话题 。 在 
内 核 部 分 可 以 看 到 无 论 虚 拟 内 存 还 是 物理 内 存 ， 其 基本 管理 单位 都 是 以 页 为 单位 ， 对 于 32 
位 ARM Android 系统 中 默认 为 枢 。 在 Android 用 户 层 生活 着 Dalvik 虚拟 机 系统 与 应 用 进 
程 以 及 系统 Deamon, 本 章 分 析 它 们 的 虚拟 内 存 是 如 何 使 用 的 以 及 其 与 4 区 内存 页 面 的 关系 。 


13.1 Dalvik 内 存 管理 


Dalvik 的 内 存 分 配 回收 机 制 直接 建构 在 Bionic C 库 的 内 存 管 理 之 上 ,物理 上 属于 Bionic 
的 一 部 分 ， 包 括 内存 分 配 与 回收 两 个 方面 。 前 者 接 驳 于 Dalvik 的 对 象 分 配 机 制 ， 后 者 接 驳 
与 Dalvik 垃圾 回收 机 制 。 

用 户 层 的 虚拟 使 用 ， 有 堆 和 栈 两 种 方式 ， 栈 的 实现 非常 简单 ， 连 续 的 向 着 某 个 方向 增 
长 或 弹出 ， 只 要 阅读 完 内 核 部 分 的 虚拟 内 存 管理 ， 就 明白 了 二 进 制 线程 栈 的 机 理 ，Java 栈 
的 分 析 请 参见 解释 器 部 分 ， 这 里 的 分 析 对 象 是 堆 机 制 。 


13.1.1 虚拟 内 存 分 配 


用 户 层 虚拟 内 存 的 分 配 前 提 是 该 段 待 分 配 虚拟 内 存 地 址 被 内 核 确认 为 有 效 ， 即 通过 
map 机 制 在 内 核 层 面 的 进程 虚拟 内 存 管 理 结构 中 分 配 出 该 段 内 存 的 地 址 。 然 后 用 户 层 通过 
malloc 在 进行 分 割 得 到 适合 用 户 代 码 使 用 的 更 小 虚拟 内 存 段 。 但 是 这 个 分 配 内 存 段 却 不 能 
保证 其 有 着 实际 对 应 的 物理 内 存 。 原 因 在 于 ， 物 理 内 存 都 是 成 页 分 配 并 挂 载 到 页 表 项 的 ， 
通常 以 4K 为 单位 。 这 个 4K 物理 内 存 有 着 对 应 4K 的 虚拟 内 存 地 址 ， 而 物理 内 存 的 分 配 是 
在 4K 地 址 中 第 一 次 写 操作 时 发 生 的 。 所 认 用 户 层 malloc 出 来 的 内 存 段 所 在 4K 虚拟 内 存 
之 前 就 被 写 访问 过 ， 则 其 malloc 之 初 就 有 着 对 应 的 物理 内 存 ， 否 则 这 个 虚拟 内 存 只 是 一 个 
数字 的 概念 .在 有 着 SWAP 机 制 的 系统 里 , 这 些 物 理 内 存 还 存在 随时 被 shrink out 和 demand 
in 的 可 能 。 

在 用 户 态 每 一 次 对 malloc 进行 写 操作 以 及 第 二 次 以 后 读 操作 时 , 都 有 可 能 导致 当前 线 
程 的 休眠 ， 其 原因 在 于 有 可 能 引起 物理 内 存 分配 ， 而 每 次 物理 内 存 分 配 都 有 可 能 导致 脏 页 
回 写 、demand in 等 导致 休眠 的 动作 。 所 以 代码 执行 时 间 是 要 关注 的 ， 永远 都 要 提防 malloc 
出 来 的 内 存 。 

回 到 正题 ，malloc 的 内 存在 C 库 里 有 着 基本 管理 结构 ， 这 个 结构 尽管 用 编程 看 不 到 ， 
但 它 就 在 进程 空间 存在 着 ， 该 管理 结构 定义 如 下 : 
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struct malloc chunk { 


Siz t prev foot; /*Size of previous chunk (if free)*/ 
size 七 head; /*Size and inuse bits*/ 
struct malloc chunk* fq; /*double links -- used only if free*/ 


struct malloc chunk* bk; 


}; 


(1) 成 员 变量 size_t prev_foot: 在 相 邻 的 前 面 那 块 内 存 块 空闲 〈free) 时 ， 记 录 前 面 那 
块 内 存 块 的 大 小 。 

(2) 成 员 变量 size_ thead， 高 30 位 记录 本 块 内 存 的 大 小 ， 第 0 位 记录 前 面 一 块 内 存 是 
否 已 经 被 分 配 〈 正 在 使 用 中 )， 第 1 位 记录 本 块 内 存 是 否 已 经 被 分 配 。 

(3) 成 员 变量 struct malloc_chunk* fd; struct malloc_chunk* bk: 只 在 该 块 内 存 空 闲 时 有 
用 ， 是 smallbin 和 treebin 的 节点 

malloc 与 Dalvik 之 间 关 系 是 , Dalvik 虚拟 机 本 身 以 及 系统 的 一 些 native 函数 和 deamon 
使 用 malloc, 当 Dalvik 进行 对 象 分 配 时 , 实质 上 是 在 虚拟 内 存 中 分 配对 象 大 小 的 内 存 空间 ， 
也 使 用 该 函数 。 

malloc 的 实现 有 多 种 方式 ， 在 Android Bionic 库 里 分 配 一 块 内 存 ， 首 先 从 smallbin 里 
找 空闲 的 内 存 块 , 若 没 有 找到 则 使 用 smallbin 里 更 大 的 内 存 块 分 割 。 若 还 不 满足 就 从 treebin 
树 里 寻找 适合 节点 ， 若 还 不 行 ， 就 需要 使 用 系统 调用 单独 map 大 块 内 存 或 者 扩大 struct 
malloc_state 尺寸 。 

//bionic c 库 的 malloc 实现 函数 

Void* mspace malloc (mspace msp, size t bytes) { 


mstate ms = (mstate)msp; 


if (!PREACTION (ms)) { 
void* mem; 


size t nb; 


// MAX_SMALL _ REQUEST 默认 值 是 254 
if (bytes <= MAX SMALL REQUEST) { 


// 算 出 大 小 为 nb 的 内 存 块 对 应 的 smallbin 索引 
idx = small index (nb); 
// mspace 的 smallmap 位 图 指出 ， 是 否 有 空闲 的 对 应 尺寸 内 存 块 


smallbits = ms->smallmap >> idx; 


if ((smallbits & 0x3U) != 0) { /*Remainderless fit to a smallbin*/ 
mchunkptr b, p; 
idx += ~smallbits & 1; /*Uses next bin if idx empty*/ 


// 从 smallbin 链表 里 取出 这 个 空闲 的 内 存 块 

b= smallbin at(ms, idx); 

p = b->fqd; 

assert (chunksize(p) == small index2size (idx)); 


unlink first small chunk(ms, b, p, idx); 
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/* 将 本 块 的 head 里 面 填 上 该 内 存 块 的 大 小 ， 并 且 将 下 一 个 内 存 块 的 heaq 变量 里 的 
PINUSE BIT 置 位 ， 因 为 从 下 一 个 内 存 块 的 角度 看 来 ， 前 面 的 内 存 块 处 于 已 分 配 状态 */ 
set_inuse_and pinuse(ms, p, small index2size (idx)); 
mem = chunk2mem (p); 
check malloced chunk (ms, mem, nb); 
goto postaction; 

} 


else if (nb > ms->dvsize) { 


if (smallbits != 0) { /*Use chunk in next nonempty smallbin*/ 
/* 没 有 找到 正好 适合 nb 的 空闲 内 存 块 ， 但 是 smallbin 链表 里 还 有 更 大 的 空闲 内 存 待 


分 配 */ 


binmap t leastbit = least bit(leftbits); 
compute bit2idx(leastbit, i); 
// 找 到 最 适合 


b = smallbin at(ms, i); 


unlink first small chunk(ms, b, p, i); 
rsize = small index2size(i) — nb; 
/*Fit here cannot be remainderless if 4byte sizes*/ 
if (SIZE T SIZE != 4 && rsize < MIN CHUNK SIZE) 
set_ inuse and pinuse(ms, p, small index2size(i)); 
else { 
set_ size and pinuse of inuse chunk(ms, p, nb); 
//r 是 切 完 之 后 剩 下 的 邦 一 块 
r= chunk plus offset(p, nb); 
set_ size and pinuse of free chunk(r, rsize); 
// 可 怜 的 r， 被 当成 dv 了 


replace dv(ms, r, rsize); 


} 
else if (ms->treemap != 0 && (mem = tmalloc small(ms, nb)) != 0) { 
// 需 要 分 配 的 size 足够 大 ， 那 就 从 tree 里 分 配 好 了 

check malloced chunk(ms, mem, nb); 

goto postaction; 


上 


} 
else if (bytes >= MAX REQUEST) 
/* 特 大 块 内 存 使 用 情况 较 小 ， 仅 在 某 些 架 构 不 够 优化 的 系统 deamon 里 出 现 ， 需 直接 向 内 核 map 
出 来 */ 
nb = MAX SIZE T; 
else { 


nb = pad request (bytes); 
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// 前 面 smallbin 和 treebin 里 都 没有 适合 的 ， 那 就 …… 又 是 挨 砍 最 多 的 dv 
if (nb <= ms->dvsize) { 
// 从 dv 里 砍 一 刀 


size 七 rsize = ms->dvsize - nb; 
mchunkptr p = ms->dv; 
if (rsize >= MIN CHUNK SIZE) { /*split dv*/ 


set_ size and pinuse of inuse chunk(ms, p, nb); 


} 


else { /*exhaust dv*/ 
//qv 彻底 牺牲 掉 了 


size t dvs = ms->dvsize; 


set_ inuse and pinuse(ms, p, dvs); 
} 
} 
else if (nb < ms->topsize) { /*Split top*/ 
//nb 足够 大 ， 又 小 于 当前 库存 的 free 内 存 ， 从 top 里 砍 
size t rsize = ms->topsize -= nb; 
mchunkptr p = ms->top; 


goto postaction; 
} 
// 超 大 内 存 的 分 配 ， 直 接 使 用 系统 调用 ， 获 得 大 块 虚拟 地 址 


mem = sys_alloc(ms, nb); 


} 

随 着 应 用 的 运行 ， 对 内 存 的 需求 越 来 越 大 ， 若 导致 虚拟 内 存 空间 的 增长 ， 需 要 向 系统 
申请 更 多 的 虚拟 内 存 。 通 常情 况 下 ， 新 申请 的 虚拟 内 存 与 原 有 虚拟 内 存 地 址 是 连续 的 。 在 
申请 完成 之 后 需要 将 其 管理 结构 与 原 有 虚拟 内 存 合 并 起 来 。 

/* 向 系统 申请 虚拟 内 存 */ 


static void* sys alloc(mstate m, size t nb) { 


/* 对 于 大 块 虚拟 内 存 (小 于 mparams .mmap_threshold) 的 分 配 ， 可 以 通过 三 种 方式 进行 ， 
代码 里 有 详细 的 注释 ， 请 读者 自行 阅读 ， 这 里 不 介绍 */ 


if (tbase != CMFAIL) { 
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} 
else { 
/ *# 已 经 分 配 了 一 块 内 存 区 域 ， 下 面 要 在 这 个 mstate 的 msegment seg; 链 表 中 寻找 一 块 合 
适 的 区 域 与 新 分 配 的 这 块 内 存 区 域 合 并 */ 
msegmentptr sp = &m->seg; 
while (sp != 0 && tbase != sp->base + sp->size) 
sp = sp->next; 
if (sp != 0 && 
!is extern segment (sp) && 
(sp->sflags & IS MMAPPED BIT) == mmap flag && 
segment holds(sp, m->top)) { /*append*/ 
/* 找 到 一 个 既 有 的 内 存 区 域 ， 该 区 域 的 结束 地 址 是 新 分 配 区 域 的 起 始 地 址 ， 合 并 之 ， 在 
Android 系统 中 这 是 最 常 发 生 的 情况 ， 占 了 system allocation 的 99% 以 上 的 概率 */ 
sp->size += tsize; 
init top(m, m->top, m->topsize + tsize); 
} 


else { 


if (sp != 0 && 
!is extern segment (sp) && 
(sp->sflags & IS MMAPPED BIT) == mmap flag) { 
/* 找 到 一 个 既 有 的 内 存 区 域 ， 该 区 域 的 起 始 地 址 就 是 新 分 配 区 域 的 结束 地 址 ， 合 并 之 */ 
char* oldbase = sp->base; 
sp->base = tbase; 
sp->size += tsize; 
return prepend alloc(m, tbase, oldbase, nb); 
} 
Else 
/* 没 有 任何 一 个 寻 有 内 存 区 域 与 新 分 配 区 域 相 邻 ， 那 只 好 再 加 个 新 的 msegment*/ 


add segment (m, tbase, tsize, mmap flag); 


if (nb < m->topsize) { /*Allocate from new or extended top space*/ 


// 真 正 的 nb 分 配 时 刻 
size 七 rsize = m->topsize -= nb; 


mchunkptr P = m->top; 


return chunk2mem(p); 
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/* 新 的 segment， 关 于 segment 与 mstate 的 分 析 ， 在 malloc.c 文件 的 头 部 有 着 详细 的 注释 ， 
请 读者 自行 阅读 */ 
static void add segment (mstate m, char* tbase, size t tsize, flag t mmapped) 


{ 
char* old top = (char*)m->top; 


/*mstate 的 top 指向 新 分 配 区 域 ， 因 为 姨 有 的 top segment 满足 不 了 nb size 的 分 配 要 
求 ， 而 新 分 配 内 存 区 域 可 以 ， 这 就 是 替换 的 原因 */ 

init top(m, (mchunkptr)tbase, tsize - TOP FOOT SIZE); 

/* 把 新 的 segment 挂 到 mstate 的 msegment seg; 链 表 上 ， 典 型 的 链 头 操作 */ 


set size and pinuse of inuse chunk(m, sp, ssize); 
*ySS = m->seg; /*Push current record*/ 


// 基 址 


m->seg.base = tbase; 


/* 原 有 的 segmnet 根据 大 小 被 挂 到 bin 链表 或 者 tree 中 ， 供 小 内 存 使 用 */ 
if (csp != old top) { 
mchunkptr q = (mchunkptr)old top; 


insert chunk(m, q, psize); 


} 
} 


13.1.2 ”内 存 回收 


在 分 析 完 内 存 分 配 之 后 ， 内 存 回 收 就 易于 理解 了 。 内 存 释 放 算 法 最 大 可 能 地 合并 出 连 
续 内 存 块 ， 在 top 块 以 后 的 空闲 内 存 过 大 时 进行 tim 操作 ， 但 是 该 算法 存在 一 个 不 足 是 : 

在 top 块 之 前 如 果 出 现 了 连续 的 空闲 内 存 ， 即 使 这 片 连续 的 物理 内 存 不 被 使 用 ， 仍 然 
占用 物理 内 存 。 因 为 这 片 内 存 是 使 用 过 匿名 内 存 ， 在 没有 swap 机 制 的 手持 设备 上 即 不 被 
换 出 ， 又 无 法 释放 。 

/7 内存 块 释放 函数 

void mspace free (mspace msp, void* mem) { 


if (mem != 0) { 


if (!PREACTION (fm)) { 
check inuse chunk (fm，P) 
if (RTCHECK (ok address(fm, p) && ok cinuse(p))) { 
size t psize = chunksize(p); 


mchunkptr next = chunk plus offset(p, psize); 
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/* 检 查 前 面 的 内 存 块 是 否 处 在 free 状态 */ 
if (!'pinuse(p)) { 
/* 前 面 的 内 存 块 free， 则 找 出 前 面 内 存 块 的 大 小 */ 


size t prevsize = p->prev foot; 


if 


((prevsize & IS MMAPPED BIT) != 0) { 


/* 前 面 内 存 块 是 直接 map 出 来 的 ， 合 并 ummap 掉 */ 

prevsize &= ~IS MMAPPED BIT; 

psize += prevsize + MMAP FOOT PAD; 

if (CALL MUNMAP ((char*)p - prevsize, psize) == 0) 


fm->footprint -= psize; 


goto postaction; 


} 


else { 


// 算 出 前 面 内 存 块 的 指针 prev 


mchunkptr prev = chunk minus offset(p, prevsize); 
// 两 块 内 存 块 可 以 合并 ， 尺 寸 相 加 


psize += prevsize; 


p = prev; 


if (RTCHECK (ok next(p, next) && ok pinuse(next))) { 
// 检 查 下 一 个 内 存 块 的 状态 是 否 free 


if 


(!cinuse (next)) { /*consolidate forward*/ 


// 下 一 个 内 存 块 处 于 free 状态 ， 可 以 向 下 合 
if (next == fm->top) { 


} 


/* 下 一 个 内 存 块 是 本 mspace 的 top 块 , 这 里 是 自由 世界 的 边界 。 将 本 内 存 块 释放 
到 自由 内 存世 界 里 去 */ 
size t tsize = fm->topsize += psize; 
fm->top = p; 
p->head = tsize | PINUSE BIT; 
if (p == fm->dv) { 
fm->dv = 0; 
fm->dvsize = 0; 
} 
/* 本 mspace 是 否 占用 了 过 多 的 虚拟 内 存 ， 如 果 超过 边界 ， 释 放 掉 过 多 的 虚拟 内 存 */ 
if (should trim(fm, tsize)) 
sys_trim(fm, 0); 


goto postaction; 


else if (next == fm->dv) { 


//next 内 存 块 是 dv 内 存 块 ， 好 吧 ， 把 本 块 内 存 也 合并 上 去 
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size t dsize = fm->dvsize += psize; 
fm->dv = p; 
set size and pinuse of free chunk(p, dsize); 
goto postaction; 
} 
else { 
// 普 通 的 向 前 内 存 块 合并 操作 
size t nsize = chunksize (next); 
psize += nsize; 


unlink chunk(fm, next, nsize); 


} 
} 
Else 
/* 无 法 向 前 合并 内 存 ， 也 得 清除 next 内 存 块 的 PINUSE_BIT 标志 */ 


set free with pinuse(p, psize, next); 


// 把 本 块 内 存 挂 到 smallbin 链表 或 者 tree 里 
insert_ chunk (fm, p, psize); 

check free chunk(fm, p); 

goto postaction; 


13.2 Ashmem 


匿名 内 存 ， 在 PC 和 服务 器 环境 下 ， 内 核 可 以 使 用 SWAP 机 制 将 不 频繁 使 用 的 内 存 页 
面 释放 掉 。 最 早期 的 Android 系统 也 尝试 采用 这 种 方式 来 节省 内 存 空间 ， 其 做 法 是 为 每 个 
Dalvik 进程 创建 一 个 临时 的 位 于 非 易 失 存储 介质 的 物理 文件 , 将 Dalvik 的 匿名 虚拟 内 存 空 


间 MAP 


到 这 个 文件 上 。 这 种 做 法 与 SWAP 的 机 理 完 全 相同 ， 即 利用 内 核 的 换 入 换 出 机 制 


节省 空间 了 。 
但 是 随 着 Android 演进 ，Ashmem 替换 掉 了 原 有 做 法 。 尽 管 作 为 既 有 内 存 机 制 的 包装 


和 利用 ， 


Ashmem 不 是 一 个 架构 性 的 革新 ， 但 是 Ashmem 有 两 个 值得 称道 的 地 方 ， 一 是 更 


方便 的 进程 间 共 享 内 存 ， 二 是 更 无 颖 的 控制 虚拟 匿名 内 存 对 应 的 物理 内 存 页 面 的 保留 和 


释放 。 


在 研究 Ashmem 之 前 ， 先 回顾 一 下 ramfs， 在 rootfs 分 析 中 遇 到 过 ramfs， 那 里 ramfs 
作为 rootfs 内 容 的 实体 出 现 过 。 在 实现 形式 上 ，ramfs 是 一 个 真正 的 文件 系统 ， 其 不 同 之 处 
是 它 没有 非 易 失 存储 介质 ， 所 有 的 内 容 都 位 于 其 节点 的 Page Cache 中 。Ashmem 机 制 下 ， 
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每 个 进程 的 匿名 虚拟 内 存 都 有 着 一 个 ramfs 的 节点 。 
// 在 用 户 态 使 用 虚拟 匿名 内 存 之 前 要 做 MMAP 操作 
static int ashmem mmap (struct file *file, struct vm area struct *vma) 


{ 


if (!asma->file) { 
/* 基 于 传统 共享 内 存 机 制 ， 为 该 虚拟 匿名 内 存 创建 ramfs 节点 */ 


vmfile = shmem file setup (name, asma->size, vma->vm flags); 

} 
} 
/*Ashmem 基于 共享 内 存 机 制 实现 ， 而 无 论 是 否 配置 了 tmpfs， 共 享 内 存 又 是 基于 ramfs 来 实现 */ 
struct file *shmem file setupl(const char *name, loff t size, unsigned long 


flags) 
{ 


// 在 ramfs 创建 一 个 节点 
inode = shmem get inode (root->d sb, NULL, S_IFREG | S_IRWXUGO, 0, flags); 


// 为 该 节点 其 生产 file 
file = alloc file(gpath, FMODE WRITE | FMODE READ, &shmem file 
operations); 


} 


有 了 这 层 MAP 铺垫 之 后 , 虚拟 匿名 内 存 发 生 的 页 异常 都 被 mt shmem_getpage(…) 捕 获 
掉 ， 接 下 来 就 是 内 核 中 典型 的 page cache 申请 操作 。 再 接 下 来 ， 又 是 Linux 虚拟 内 存 的 基 
本 运行 机 制 的 老 故 事 了 ， 雨 打 风 吹 ， 换 入 换 出 ， 周 而 复 始 。 

但 是 ， 作 为 基于 page cache 的 文件 系统 ,ramfs 是 没 法 换 入 换 出 的 ， 如 果 匿 名 内 存 的 物 
理 页 不 过 就 是 待 在 那里 ， 这 跟 普 通 的 非 SWAP 机 制 的 匿名 虚拟 内 存 有 什么 区 别 呢 ? 
到 Malloc， 可 以 看 到 ， 应 用 运行 时 对 内 存 的 使 用 是 不 停 地 分 配 、 释 放 ， 这 当中 会 频 
繁 出 现 整 页 的 空闲 虚拟 内 存 。 而 这 时 候 ， 内 核 并 不 知道 这 个 页 面 是 可 以 释放 掉 的 。 因 为 是 
匿名 内 存 ， 内 核 只 能 在 其 不 活跃 时 将 其 换 出 , 但 是 这 个 页 面 并 不 一 定 处 在 LRU 的 队 尾 。 所 
以 这 个 时 候 就 需要 用 户 态 通知 内 核 将 这 个 页 面 释放 掉 ， 而 Android 的 确 是 这 样 做 的 。 所 以 ， 
基于 ramfs， 这 个 动作 就 显得 非常 自然 ， 将 其 page cache 对 应 页 面 truncate 即 可 。 

/* 内 核 记录 下 来 所 有 的 空闲 无 用 内 存 段 , 待 内 核发 现 内 存 紧 张 ,需要 shrink 内 存 ,或 者 在 Android 

下 发 ASHMEM PURGE ALL _CACHES 命令 时 ， 删 去 无 用 页 面 */ 

static int ashmem shrink(struct shrinker *s, struct shrink control *sc) 


{ 


瑟 


list for each entry safe(range, next, &ashmem lru list, rv) € 
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/* 内 核 中 典型 的 page cache 清洗 函数 ， 将 删除 inode 节点 对 应 在 start 到 end 范围 内 
的 所 有 page cahe 页 面 */ 


vmtruncate range (inode， start, end); 


} 


上 文 的 源码 分 析 里 略 去 了 Ashmem 共享 映射 相关 的 代码 ,而 Ashmem 是 借助 传统 的 共 
享 内 存 机 制 和 Binder FD 来 实现 其 内 存 共享 机 制 。Ashmem 只 是 其 上 的 一 层 克 ， 这 里 不 必 
再 重复 讨论 ， 相 关机 制 参 见 虚 拟 内 存 和 Binder 章节 。 


13.3 GC 


尽管 涉及 线程 与 虚拟 机 对 象 管理 机 制 等 方面 的 问题 , 但 是 这 些 问 题 属于 Dalvik 的 其 他 
子 系统 ，GC 本 质 还 是 Dalvik 内 存 管理 问题 。 对 于 Dalvik GC 而 言 基 本 分 配 回收 算法 已 被 
bionic 实现 ， 而 且 也 许 为 了 规避 专利 陷阱 ，Dalvik 的 GC 机 制 只 实现 了 基本 的 marksweep 
策略 ， 所 以 Mark 机 制 理解 清楚 了 ，Dalvik GC 的 架构 就 清晰 了 。 


13.3.1 对 象 Mark 


Mark 试图 将 被 引用 中 对 象 标 记 出 来 , 在 引用 链 中 遍历 到 一 个 对 象 后 , 需要 区 分 该 对 象 
的 类 型 ， 下 面 展开 分 析 基 本 的 普通 对 象 。 
// 对 象 遍 历 的 基本 函数 


static void scanObject (const Object *obj, GcMarkContext *ctx) 
{ 
if (obj->clazz == gDvm.classJavaLangClass) { 
/* 类 对 象 的 遍历 ， 除 了 数据 域 还 要 遍历 其 静态 域 ， 这 是 类 对 象 特 有 的 情况 */ 
scanClassObject (obj, ctx); 
} else if (IS_ CLASS FLAG SET(obj->clazz, CLASS ISARRAY)) { 
// 若 是 数组 对 象 ， 进 一 步 对 数组 里 的 每 一 个 对 象 执行 scanArrayObject 
scanArrayObject (obj, ctx); 
} else { 
// 普 通 对 象 ， 这 是 展开 分 析 的 情况 
scanDataObject (obj, ctx) ; 
} 
} 


/* 普 通 对 象 的 遍历 ， 需 要 将 该 对 象 所 占用 的 内 存 标记 为 占用 ， 而 且 要 沿 着 该 对 象 数据 域 再 深 一 步 地 
遍历 该 对 象 所 引用 的 下 一 级 对 象 */ 
static void scanDataObject (const Object *obj, GcMarkContext *ctx) 
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// 将 该 对 象 对 应 的 位 图 标记 为 占用 
markObJject ( (const Object *)obj->clazz, ctx); 
/* 继 续 沿 着 该 对 象 的 数据 域 扫描 ， 将 该 对 象 使 用 的 对 象 标记 为 占用 */ 


scanFields (obj， ctx) 


13.3.2 ”从 Root 对 象 集 到 普通 对 象 


GC 从 root 对 象 开 始 遍 历 引用 链 ，root 对 象 包括 加 载 的 类 (也 作为 普通 的 对 象 存在 于 
Dalvik)、 原 始 对 象 、 全 局 引用 及 间接 引用 表 。 而 与 大 量 Java 应 用 相关 对 象 的 遍历 是 顺 着 
thread 的 遍历 进入 的 ， 从 而 导致 大 量 生成 对 象 及 其 引用 对 象 的 扫描 。 

//Root 对 象 集 扫描 入 口 


void dvmVisitRoots (RootVisitor *visitor, void *arg) 


{ 


， 


// 已 加 载 的 类 
visitHashTable (visitor, gDvm.loadedClasses, ROOT STICKY CLASS，arg) 
// 原 始 对 象 类 


visitPrimitiveTypes (visitor, arg); 


// 全 局 引用 及 间接 引用 表 
visitIndirectRefTable (visitor，&gDvm.jniGlobalRefTable，0，ROOT JUNI_ 
GLOBAL, arg) 


visitReferenceTable (visitor，&gDvm.jniPinRefTable，0，ROOT VM_ 
INTERNAL, arg); 


// 线 程 的 遍历 


visitThreads (visitor, arg); 


// 遍 有 历 线程 ， 这 里 最 值得 关注 的 是 对 线程 stack 的 遍历 


static void visitThread (RootVisitor *visitor, Thread *thread, void *arg) 


{ 


threadId = thread->threadId; 

// 遍 历 线程 对 象 本 身 

(*visitor) (gthread->threadObj, threadId, ROOT THREAD OBJECT, arg); 
// 遍 历 线 程 异常 对 和 象 

(*visitor) (gthread->exception, threadId, ROOT NATIVE STACK, arg); 


// 遍 历 java 栈 
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VisitThreadStack (visitor, thread, arg); 


Java 栈 的 遍历 ， 将 遍历 层次 递 进 到 一 个 Java 线程 运行 时 产生 的 对 象 引 用 层面 上 。 其 中 
Dalvik 栈 的 结构 参见 本 书 相关 章节 。 

// 遍 历 Java 栈 

static void visitThreadStack (RootVisitor *visitor, Thread *thread, void 


*arg) 


// 逐 帧 处 理 

for (u4 *fp = (u4 *)thread->interpSave.curFrame; 
fp != NULL; 
fp = (u4 *)saveArea->prevFrame) { 
Method *method; 


SaveArea = SAVEAREA FROM FP (fp); 
method = (Method *) saveArea->method; 


// 检 查 该 帧 函数 所 占用 的 寄存 器 
if (method != NULL && !dvmIsNativeMethod(method)) { 


if (regVector == NULL) { 


/* 没 有 获得 regVector， 则 逐个 检查 该 函数 寄存 器 获 盖 的 内 存 ， 若 为 对 象 则 执 
行 遍历 操作 */ 
for (size t i = 0; i < method->registersSize; ++i) { 
// 检 查 是 否 为 有 效 对 象 
if (dvmIsValidObject((Object *)fp[i])) { 
// 遍 爵 
(*visitor) (gfp[i], threadId, ROOT JAVA FRAME, arg); 


} 


} else { 


u2 bits = 1 << 1; 
// 可 以 直接 定位 对 象 位 置 ， 则 取出 对 象 ， 扫 描 之 


for (size t i = 0; i < method->registersSize; ++i) { 


if ((bits & Ox1) != 0) { 
// 遍 历 
(*visitor) (gfp[i], threadId, ROOT _ JAVA FRAME, arg); 
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13.3.3 ”GC 与 线程 实时 性 


GC 是 实时 性 的 克星 ， 是 Java 进入 实时 领域 致命 性 的 障碍 。 原 因 在 于 在 GC 线程 活跃 
时 首先 要 将 该 Java 进程 的 所 有 线程 suspend 掉 再 进行 GC， 和 否则 GC 的 结论 是 错误 的 。 

在 GC 线程 侧 ， 首 先 调 用 void dvmSuspendAllThreads 通知 其 他 Java 线程 进入 suspend 
状态 ， 其 他 Java 线程 的 解释 器 在 每 条 指令 处 理 完毕 都 要 调用 void dvmCheckBefore 检查 
union InterpBreak 的 uint16 t subMode; 日 是 否 需 要 suspend， 若 条 件 成 立 ， 则 调用 
dvmCheckSuspendPending 进入 suspend 状态 。 


/*GC 线程 侧 调用 该 函数 停 掉 Java 进程 */ 
void dvmSuspendAllThreads (SuspendCause why) 
{ 
/ /扫描 DVM 进程 中 所 有 的 Java 线程 
for (thread = gDvm.threadList; thread != NULL; thread = thread->next) { 


if (thread == self) 
continue; 


/* 将 每 个 thread 的 int suspendCount 加 一 ， 且 设置 union InterpBreak 的 
uint16_t subMode; 状 态 ,该 thread 将 以 int suspendCount 和 uint16 t subMode; 
状态 作为 是 否 需要 suspend 的 条 件 */ 
dvmAddToSuspendCounts (thread, 1, 

(why == SUSPEND FOR DEBUG || 

why == SUSPEND FOR DEBUG EVENT) 

学 和 人 和 让 


for (thread = gDvm.threadList; thread != NULL; thread = thread->next) { 


/* 等 待 该 thread 休眠 ， 若 等 待 时 间 超 过 一 定时 限 ， 则 提升 该 线程 的 优先 级 ， 若 该 线程 
处 于 运行 态 只 不 过 没有 被 调度 上 CPU， 该 动作 有 效 */ 
waitForThreadSuspend(self, thread); 


F 


//Java 线程 侧 在 每 条 指令 结束 之 后 调用 该 函数 
void dvmCheckBefore(const u2 *pc, u4 *fp, Thread* self) 


' 
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/* 对 于 GC 情况 ，suspendCount 为 真 */ 


if (self->suspendCount || 
(self->interpBreak.ctl.subMode & kSubModeCallbackPending)) { 


/* 这 里 检查 当前 结束 的 指令 属性 是 否 为 kInstrCanBranch | kInstrCanSwitch | 
kInstrCanThrow | kInstrCanReturn 中 的 一 种 ， 即 Java 线程 在 跳 转 返回 且 不 会 产 
生 异 常 时 才 接 受 GC 的 Suspend 请 求 */ 

if (flags & (VERIFY GC INST MASK & ~kInstrCanThrow)) { 


// 检查 GC 是 否 活跃 

if (self->suspendCount) { 
dvmExportPC (pc, fp); 
// 进 入 suspend 
dvmCheckSuspendPending (self); 


} 

} 

由 此 可 以 总 结 GC 对 实时 性 的 影响 主要 是 导致 线程 不 可 控 、 不 可 预测 的 Suspend。 在 
GC 对 Java 线程 Suspend 的 处 理 分 为 以 下 儿 种 情况 。 

(1) 处 于 运行 态 且 获 得 处 理 器 的 线程 ， 这 种 情况 只 要 遇 到 跳 转 返回 指令 即 可 。 

(2) 处 于 运行 态 但 没有 获得 处 理 器 的 线程 ， 这 种 情况 提升 其 优先 级 将 有 效 解决 问题 。 

(3) 处 于 非 运行 态 Java 线程 ， 这 种 线程 在 重新 恢复 运行 时 需要 检查 int suspendCount 
和 uint16_t subMode; 以 等 待 GC 完成 。 

另外 GC 自身 的 效率 也 是 影响 实时 性 的 关键 因素 , 因为 GC 的 效率 决定 了 线程 Suspend 


时 间 的 长 度 。 
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14.1 Dalvik 虚拟 机 的 进程 


在 Dalvik 新 进程 创建 的 最 关键 一 步 是 使 用 Linux 的 Fork 机 制 从 zygote 母体 Fork 出 一 
个 新 的 进程 来 。 到 了 这 里 有 如 下 值得 关注 的 地 方 。 

(1) 由 于 是 Linux 的 Fork 机 制 ， 新 进程 复制 Zygote 的 可 共享 虚拟 地 址 空间 的 页 表 页 
目录 。 而 不 可 共享 区 域 由 Linux 自身 的 COW 机 制 在 写 时 机 创建 。 

(2) Zygote 已 经 进行 大 量 的 初始 化 ， 加 载 了 大 量 的 常用 类 库 和 二 进 制 链接 库 ， 都 被 新 
进程 继承 下 来 。 

(3) 新 进程 如 果 有 什么 异常 状况 , 可 以 轻易 被 kemel 杀 掉 , 只 要 systemserver 跟 Zygote 
没有 问题 ， 系 统 仍然 可 以 健康 的 运行 。 

(4) 在 新 进程 运行 应 用 代码 之 前 构建 Android 进程 安全 框架 。 除了 传统 的 通过 用 户 ID、 
组 ID 将 进程 文件 访问 限制 在 自己 局 部 区 域 ， 通 过 Capabilities 能 力 位 更 加 细 分 地 控制 对 内 
核 访问 。 

//Zygote Fork 新 进程 的 实现 函数 

static pid t forkAndSpecializeCommon (Const u4* args, bool isSystemServer) 


, 
pid t pid; 


// 新 进程 的 UID 和 GID， 这 是 在 由 PackagemangeService 传送 过 的 
uid t uid = (uid t) args[0]; 


// 调 用 Linux 系统 调用 Fork 

pid = fork(); 

// 完 成 Fork 动作 ， 新 老 进程 都 从 这 里 返回 
if (pid == 0) { 


至 此 新 进程 的 实体 被 创建 完毕 ， 但 是 这 离 Android 进程 还 有 几 步 要 走 。 首 先 这 是 由 
Zygote Fork 出 的 进程 ， 它 具有 与 Zygote 相同 的 权限 ， 这 是 不 被 允许 的 , 不 然 Android 上 的 
恶意 病毒 就 可 以 为 所 欲 为 了 。 而 新 进程 到 了 这 里 还 没有 加 载 APK 的 .so 和 dex， 所 以 新 进 
程 在 这 里 自 废 武功 限制 自己 以 后 的 所 为 ， 等 到 加 载 了 恶意 的 APK 也 不 怕 伤 及 筋骨 了 。 

新 版 Android 的 安全 性 更 进一步 , 支持 基于 Selinux 的 面向 企业 应 用 的 更 高 级 别 的 安全 
性 ， 但 是 本 节 摘 自 较 早 笔记 ， 其 版 本 没有 涉及 Selinux 的 适 配 。 为 了 避免 主题 分 散 ， 针 对 
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SEAndroid/SElinux 的 分 析 不 在 本 书 讨 论 的 范围 之 内 。 
#ifdef HAVE ANDROID OS 
gE (uid != 0) { 
#endif J 


// 重 置 用 户 组 


err = setgroupsIntarray (gids) 7 


// 设 置 资 源 限制 

err = setrlimitsFromArray (rlimits); 
// 重 置 GID 

err = setgid(gid) 


// 重 置 UID 


err = setuid(uid); 


//Capabilities 位 的 设置 
err = setCapabilities (permittedCapabilities, effectiveCapabilities); 


// 设 置 DVM 控制 结构 的 线程 号 
Thread* thread = dvmThreadSelf (); 
thread->systemTid = dvmGetSysThreadId () ; 


} else if (pid > 0) { 
/*the parent process*/ 


} 
return pid; 
} 
再 往 后 ， 父 子 进程 都 退 到 Zygote 中 ,但 是 父 进 程 继 续 等 待 下 一 个 新 的 DVM 进程 创建 
申请 ， 子 进程 在 清空 原 有 的 Java 栈 之 后 开始 了 新 生 。 


14.2 ”Dalvik 线程 创建 机 制 


Bionic 的 线程 机 制 是 Dalvik 线程 的 机 制 的 基础 。 其 实现 是 通过 Linux 的 Fork 机 制 来 实 
现 的 ， 这 样 Android 的 Java 线程 实际 上 就 是 不 择 不 扣 的 普通 Linux 线程 ， 其 调度 完全 受 内 
核 控制 。 

线程 的 运行 轨迹 是 栈 ， 栈 是 由 帧 组 成 ，Dalvik 线程 也 不 例外 ， 首 先 分 析 Android 代码 
注释 里 已 经 给 出 了 的 bionic 线程 的 栈 结 构 。 
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1 TLS area 


Stack area 


由 此 可 见 ， 线 程 栈 结构 是 最 低层 存放 该 线程 的 管理 结构 pthread_internal t; 接着 是 线 


程 局 部 存储 区 域 ， 再 接着 是 运行 时 产生 的 堆栈 数据 。 


线程 的 创建 实现 遵循 pthread API。 实 现 如 下 : 


int pthread create (Pthread t *thread out, pthread attr 七 const * attr, 


Void *(*start routine) (void *), void * arg) 


// 若 未 准备 堆栈 ， 则 分 配 堆栈 ， 栈 是 线程 的 人 生 轨 迹 
if (!attr->stack base) { 


stack = mkstack(stackSize，attr->guard size); 


} else { 
stack = attr->stack base; 
} 
// 预 留 线程 局 部 存储 
tls = (void**) (stack + stackSize - BIONIC TLS SLOTS*sizeof (void*)); 


/* 调 用 __pthread_clone, 传递 下 去 的 最 重要 参数 是 CLONE_VM, 意味 着 虚拟 地 址 空间 共享 ， 
即 线程 。 pthreaqd_clone 由 汇编 实现 ， 是 Bionic 的 一 部 分 ， 见 下 文 分 析 */ 
tid =  _pthread clone((int(*) (void*))start routine, tls, 

CLONE FILES | CLONE FS | CLONE VM | CLONE SIGHAND 

| CLONE THREAD | CLONE SYSVSEM | CLONE DETACHED, 


arg); 


ri _Ppthread clone 的 实现 
ENTRY(_ pthread clone) 


-Cantunwind 


/* 把 新 线程 入 口 地址 填 入 堆栈 ， 在 新 线程 从 内 核 退出 时 会 从 这 里 找到 其 实 执行 地 址 。 其 中 rl 
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是 堆栈 地 址 */ 
str r0, [rl, #-4] 
// 系 统 调用 需要 的 参数 信息 
str r3, [ri, #-8] 
// CLONE_VM 等 信息 放 在 r0， 遵 循 内 核 调用 规范 
mov 1 Pe 4 
#if ARM EABI 
// 保 存 下 来 r4-r7 
stmfd sp!; {r4, r7} 
// 系 统 调用 clone，clone 即 Fork 的 一 种 包装 


ldr rl; =_ NR Clone 
Swi #0 
#else 
Swi #_NR clone 
#endif 
// 新 线程 的 50 为 0， 参 见 内 核 部 分 
movs 次 全 > 下 全 
bt __error 
/ /创建 线程 从 这 里 返回 
bxne Er 
// 新 线程 继续 执行 


// 取 出 存放 在 新 线程 堆栈 里 起 始 地 址 和 参数 

ldr r0, [sp, #-4] 

ldr rl, [sp, #-8] 

// 新 线程 的 堆栈 指针 指向 TLS 区 域 ， 参 见 上 文 堆栈 结构 


mov Ei @ _ thread entry needs the TLS pointer 


sub Lr 
// 新 线程 继续 调用 “thread_entry 
Pb _ thread entry 


END(__pthread clone) 


// 新 线程 的 trampoline 


void _ thread _entry(int (*func) (void*), void *arg, void **t]s) 


. 


int retValue; 
pthread internal t * thrinfo; 


thrIinfo = (pthread internal t *) tls[TLS SLOT THREAD ID]; 


/ /初始化 新 线程 的 线程 局 部 存储 

init tileot tlis; thrinfo }s 

// 跳 转 到 新 线程 的 起 始 地 址 

pthread exit( (void*)func (arg) ); 
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14.3 ” Android 线程 模型 


Android 进程 天 生 是 多 进程 的 。Android 的 线程 结构 有 如 下 几 种。 

(1) 主线 程 ， 由 Zygote 母体 生成 。 

(2) 线程 池 的 线程 在 用 户 态 二 进 制 层 创建 ,但 是 同时 创建 DVM 需要 的 Context， 这些 
线程 朴 在 Binder 上 ， 实 现 Binder 协议 ， 受 Binder 事件 驱动 往 上 蹄 到 Java 层 完成 跨 进程 调 
用 (有 时 也 是 进程 内 调用 )。 

(3) Java 应 用 创建 的 线程 ， 普 通 的 Dalvik 线程 。 

(4) 在 用 户 态 二 进 制 层 创建 的 pthread 线程 没有 相应 的 DVM Contex， 无 法 蹄 到 Java 
层 ， 只 能 执行 二 进 制 机 器 码 ， 通 常 做 一 些 deamon 工作 。 

前 两 者 线程 是 Android 应 用 框架 的 默认 生成 ， 后 两 种 线程 由 应 用 、 中 间 件 生成 。 本 节 
着 重 分 析 前 两 种 线程 的 生成 。 


14.3.1 主线 程 的 生成 


在 Zygote 母体 Fork 出 Android 应 用 之 后 , 主线 程 作为 新 的 Android 应 用 的 第 一 个 线程 
就 存在 了 。 
public static final void zygoteInit (int targetSdkVersion, String[] argv) 
throws ZygoteInit.MethodAndArgsCaller { 


/* 从 这 里 创建 本 进程 的 线程 池 */ 
zygoteInitNative(); 

/* 主 线程 继续 从 这 里 演化 ，activitythread 加 载 等 工作 在 这 里 进行 */ 
applicationInit (targetSdkVersion, argv); 


) 
14.3.2 ”线程 池 线 程 的 生成 


主线 程 实体 在 Java 层 调用 class RuntimeInit 的 public static final native void 
ZygoteInitNative();。 

C++ 层 的 class AppRuntime 的 virtual void onZygoteInit() 函 数 完成 实际 的 工作 线程 创建 
工作 ， 线 程 池 的 创建 步骤 是 ， 首 先 创建 第 一 个 线程 A， 然 后 线程 A 趴 在 Binder 上 监听 
BR_SPAWN LOOPER 事件 ， 该 事件 发 生 时 ， 线 程 A 创建 线程 B， 线 程 B 继续 监听 
BR_SPAWN LOOPER 事件 ， 该 事件 发 生 时 ， 线 程 B 创建 线程 C。 所 以 线程 池 线程 一 共 会 
生成 3 个 。 这 是 Binder 协议 决定 的 ， 根 据 系统 处 理 器 数目 以 及 应 用 进程 的 负载 强度 ， 线 程 
池 线 程 的 数目 可 以 动态 调整 , 当然 这 属于 Android 优化 的 考虑 , 不 是 Google Android Release 
的 实现 。 
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Virtual void onZygoteInit() 


{ 


sp<ProcessState> proc = ProcessState::self(); 
/* 创 建 线程 池 里 的 第 一 个 线程 */ 
proc->startThreadPool (); 

} 


线程 池 的 创建 函数 与 普通 的 非 Java 线程 创建 区 别 的 是 ， 这 将 创建 具有 能 够 进入 DVM 
运行 时 能 力 的 线程 。 
int AndroidRuntime::javaCreateThreadEtc(*…) 


{ 
/*entryFunction 即 为 class PoolThread :: virtual bool threadLoop()*/ 


args[0] = (void*) entryFunction; 


/*AndroidRuntime::javaThreadShell 是 关键 的 包 于 函 数 ， 它 为 新 线程 创建 出 需要 的 DVM 
context， 且 调用 entryFunction 运行 */ 
result = androidCreateRawThreadEtc (AndroidRuntime: :javaThreadShell, args, 
threadName, threadPriority, threadSstackSize, threadId); 


int AndroidRuntime::javaThreadShell (void* args) { 


/* 为 本 线程 创建 Java 运行 所 需 的 context， 该 部 分 工作 与 Dalvik 线程 创建 一 致 ， 具 体 分 
析 见 Dalvik 线程 部 分 */ 


if (javaAttachThread (name, &env) != JNI_OK) 

return -1; 
/* 环 境 搭 好 了 , 干 活 class PoolThread :: virtual bool threadLoop()*/ 
result = (*(android thread func t)start) (userData); 


} 
线程 池 里 的 每 一 线程 都 继承 自 class PoolThread，threadLoop0 是 其 主要 工作 。 


class PoolThread : public Thread 
人 


Protected: 
/# 线 程 池 线程 的 主要 工作 ， 即 Binder 协议 的 执行 。 本 节 分 析 线 程 池 线程 的 线程 结构 ， 其 工作 内 容 


部 分 的 分 析 见 Binder 部 分 */ 
Virtual bool threadLoop() 


{ 
IPCThreadState::self()->joinThreadPool (mIsMain); 


return false; 
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14.4 _ Java 线程 转换 


本 节 分 析 线 程 从 Java 代码 调用 JNI 函 数 以 及 具有 Java 执行 能 力 的 线程 从 JNI 代 码 调用 
Java 函数 的 过 程 。 


14.4.1 


从 Java 到 JNI 


从 Java 到 JNI 即 解释 器 遇 到 了 native 函数 调用 。 这 是 从 解释 器 向 二 进 制 运行 时 转向 的 
动作 ， 发 生 在 当 解 释 器 遇 到 函数 调用 指令 ， 且 发 现 欲 调用 的 函数 是 native 类 型 。 接 下 来 以 
C 解释 器 为 例 分 析 native 函数 调用 ， 关 于 寄存 器 Context 的 处 理 在 “Dalvik 寄存 器 编译 模 
型 ”一 节 中 进行 分 析 ， 本 节 着 重 与 分 析 native 调用 相关 。 

// 解 释 器 对 invokeMethod 的 handler 

GOTO_TARGET (invokeMethod, bool methodCallRange, const Method* 


_methodToCall, 
u2 count, u2 regs) 


{ 


newSaveArea->method = methodToCall; 
if (self->interpBreak.ctl.subMode != 0) { 


} 


/*GC 或 者 调试 发 生 ， 记 下 指令 位 置 ， 准 备 在 该 当前 指令 完成 后 退出 解释 器 */ 
PC_TO_ SELF(); 
dvmReportInvoke (self, methodToCall); 


if (!dvmIsNativeMethod (methodToCall)) { 


} 


//Java 函数 的 调用 ， 不 在 本 节 分 析 
else { 


self->interpSave.curFrame = newFp; 


/* 调 用 native 函数 ,newFp 作为 参数 列表 指针 传递 给 jni native 函数 .这 里 Java 
栈 将 不 再 变化 ， 转 而 进入 二 进 制 线程 栈 。 而 实际 上 在 类 加 载 是 native 函数 ， 被 初始 
化 为 void dvmResolveNativeMethod (…) ， 这 类 似 一 个 弹簧 的 功能 ， 接 下 来 从 
这 里 再 跳 到 真正 的 native 函数 中 */ 

(*methodTocal1->nativeFunc) (newFp, &retval, methodToCall, self); 


/* 函 数 调 用 完毕 ， 退 一 帧 */ 
dvmPopJniLocals (self, newSaveArea); 
self->interpSave.curFrame = newSaveArea->prevFrame; 


fp = newSaveArea->prevFrame; 
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GOTO_TARGET END 


//native 函数 跳 转 中 间 函 数 ， 这 里 将 解析 native 函数 真正 地 址 并 跳 转 
void dvmResolveNativeMethod(const u4* args, JValue* pResult, 
const Method* method, Thread* self) 


// 在 缓冲 机 制 中 查找 该 native 函数 
DalvikNativeFunc infunc = dvmLookupInternalNativeMethod (method); 
if (infunc != NULL) { 


// 该 函数 已 被 使 用 过 

DalvikBridgeFunc dfunc = (DalvikBridgeFunc) infunc; 
// 写 入 method->nativeFunc， 下 一 次 不 用 弹簧 函数 了 
dvmSetNativeFunc ( (Method*) method, dfunc, NULL); 
// 调 用 native 函数 

dfunc(args, pResult, method, self); 

return; 


} 


/* 在 .so 库 文件 里 查找 该 native 函数 ， 本 书 没有 关于 .so 文件 查找 函数 的 分 析 ， 但 可 以 参考 
linker 一 节 ， 工 作 原 理 类 似 */ 
void* func = lookupSharedLibMethod (method); 
if (func != NULL) { 
/* 放 入 缓冲 ， 写 入 method->nativeFunc*/ 
dvmUseJNIBridge( (Method*) method, func); 
//native 函数 调用 


(*method->nativeFunc) (args, pResult, method, self); 


return; 


} 
14.4.2 从 JNI 到 Java 


JNI 调用 Java 函数 ， 本 质 上 通过 解释 器 运行 Java 字 节 码 ， 类 似 于 解释 器 遇 到 invoke 
指令 。 但 是 解释 器 处 理 invoke 函数 之 前 有 一 个 运行 时 的 Context， 包 括 调用 参数 寄存 器 分 
配 、 函 数 局 部 变量 寄存 器 分 配 、 函 数 返 回 值 寄存 器 分 配 ， 以 及 DVM 当前 状态 。 除 了 后 者 
是 现成 的 ， 其 余 Context 都 需要 动态 搭建 起 来 。 为 了 完成 这 些 工作 ，DVM 为 此 准备 了 一 个 
函数 表 ， 向 JNI 提供 不 同类 型 的 Java 函数 调用 。 


//DVM 向 JNI 提供 服务 的 函数 表 
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static const struct JNINativeInterface gNativeInterface = { 


CallByteMethod, 
CallByteMethodV, 
CallByteMethodA, 


在 JNI 层 针对 不 同类 型 的 Java 函数 选择 其 不 同 的 入 口 函 数 。 这 些 入 口 函 数 尽管 与 不 同 


类 型 的 Java 函数 有 着 不 同 的 实现 ,但 是 其 实现 方式 主体 基本 相同 , 即 借助 void dvmCallMet- 
hodX(…) 实 现 调用 。 

以 void dvmCallMethodV(…) 为 例 ， 代 码 如 下 : 

/* 这 之 前 要 找到 当前 代码 所 在 线程 Thread* self、 要 调用 的 函数 Method* method、 若 不 是 


static 函数 还 要 找 出 其 对 象 Object* obj/ 
void dvmCallMethodV (Thread* self, const Method* method, Object* obj, 


bool fromJni, JValue* pResult, va list args) 


Wi 
clazz = callPrep(self, method, obj, false); 


if (clazz == NULL) 
return; 


/*"ins" for new frame start at frame pointer plus locals*/ 
ins = ((u4*)self->interpSave.curFrame) + 


(method->registersSize - method->insSize); 


// 非 静态 函数 的 调用 要 将 对 象 放 入 context 中 
if (!dqvmIsStaticMethod (method)) { 


*inst++ = (u4) obj; 
verifyCount++; 


} 
// 根 据 参数 定义 将 参数 填 入 栈 中 
while (*desc != '\0') { 


case 'F': { 


// 浮 点 类 型 参数 
*ins++ = dvmFloatToU4 (f); 


break; 
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default: { 
/* 简 单 类 型 参数 直接 复制 */ 


站 InS++ = va_arg(args，Uu4) 7 


break; 


} 

// 进 入 解释 器 

dvmInterpret (self, method, pResult); 
//java 调用 完毕 弹 掉 java 栈 


dvmPopFrame (self); 
. 


DVM Java 函数 看 到 的 是 DVM 虚拟 机 , 其 字 节 码 直 接 操 作 虚拟 机 Context, 没有 Context 
其 字 节 码 是 没有 意义 的 ， 所 以 Context 的 准备 是 执行 DVM Java 函数 的 前 提 。 


static ClassObject* callPrep (Thread* self, const Method* method, Object* obj, 


bool checkAccess) 


ClassObject* clazz; 


// 找 到 对 应 类 
if (obj != NULL) 

clazz = obj->clazz; 
else 


clazz = method->clazz; 


if (dvmIsNativeMethod(method)) { 
//native 函数 的 调用 ， 这 里 不 考虑 


} else { 
/* 庶 拟 机 的 Context 都 在 其 Java 栈 中 存放 ， 一 个 函数 调用 Java 栈 增长 一 帧 ， 这 里 根 


据 调 用 函数 的 寄存 器 使 用 个 数 、 参 数 、 局 部 变量 所 占用 的 空间 分 配 栈 空间 。 其 格式 参见 
“Dalvik 寄存 器 模型 ”一 节 */ 


if (!dvmPushInterpFTrame (self, method)) { 


return NULL; 
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return clazz; 
} 
在 将 Java 函数 的 Context 准备 好 之 后 进入 解释 器 ， 尽 管 解释 器 物理 上 仍然 与 当前 二 进 
制 码 使 用 同一 个 栈 ， 但 逻辑 上 ， 当 前 线程 的 栈 已 经 切换 到 了 Java 栈 。 


第 1S 章 Bionic 的 动态 加 载 机 制 


一 个 OS 的 基础 组 件 中 ， 最 关键 、 使 用 最 频繁 的 就 是 C 库 ，C 库 是 系统 其 他 各 组 件 工 
作 的 基础 。5 年 前 移动 和 嵌入 式 领域 的 主流 处 理 器 还 是 ARM9, 而 Linux 软件 体系 使 用 的 C 
库 是 GLIBC。GLIBC 相对 较 大 ， 编 译 完 之 后 的 体积 足 有 8M 多 。 大 家 知道 应 用 对 C 库 的 
访问 是 必须 和 频繁 的 ， 而 一 个 大 型 的 C 库 面 临 的 问题 是 更 松散 的 系统 调用 分 布 ， 将 导致 更 
频繁 缺 页 异常 ， 对 于 当时 的 ARM9 处 理 器 GLIBC 苦 不 堪 言 。 程 序 的 启动 时 间 很 大 程度 消 
耗 在 这 个 庞大 C 库 上 。 于 是 出 现 了 裁剪 过 的 ucLibc， 但 是 出 现 了 兼容 性 问题 ， 而 且 仍旧 
过 大 。 

最 初 的 Android 设计 目标 是 400M 的 ARM9， 而 且 由 于 Android 不 需要 广泛 的 支持 大 
范围 Linux 二 进 制程 序 ，C 库 兼 容 性 的 必要 性 降低 了 。 所 以 Android 重新 设计 C 库 ， 这 是 
个 精巧 的 C 库 ， 避 免 使 用 GLIBC 和 ucLibe 而 产生 的 庞大 开销 。 最 初 的 Android 版 本 能 够 
在 ARM9 上 顺利 运行 ， 这 个 小 巧 的 C 库 功 不 可 没 。 

现在 能 入 式 和 移动 处 理 器 的 性 能 越 来 越 接近 PC， 一 颗 4 核 CA9 的 处 理 器 足以 运行 
GLIBC 了 ， 而 小 巧 高 效 Bionic 一 直 没 蔡 换 掉 ， 其 原因 也 许 在 于 由 于 Android 不 广泛 支持 二 
进 制 应 用 ， 所 以 也 不 需要 一 个 大 型 的 C 库 吧 。 

Bionic C 库 的 实现 诸如 malloc 机 制 、 线 程 机 制 等 与 系统 其 他 部 分 紧密 相关 ， 所 以 都 被 
分 散 到 了 其 他 章节 ，Bionic C 库 机 制 仅 剩 下 动态 加 载 机 制 单独 作为 本 章 的 内 容 。 

不 同 于 传统 C 库 的 1d.so，Bionic C 库 重 新 实现 Linker 来 完成 其 功能 。Linker 的 作用 是 
将 依靠 动态 链接 库 二 进 制 可 执行 程序 的 动态 链接 库 依次 找 出 来 逐个 解析 链接 ， 然 后 再 跳 到 
二 进 制 可 执行 程序 的 入 口 。 这 其 中 对 动态 库 的 链接 是 个 递归 的 过 程 ， 因 为 一 个 动态 库 可 以 
本 身 也 依赖 于 另 一 个 动态 库 ，Linker 需要 完成 这 个 递归 加 载 的 过 程 。 所 以 Linker 的 分 析 也 
需要 采用 这 个 逐 级 递归 逻辑 。 


15.1 Linker 一 一 用 户 态 人 口 


内 核 运行 新 的 基于 动态 加 载 应 用 时 ， 首 先 要 找到 其 对 应 的 加 载 器 ， 并 将 其 映射 。 在 内 
核 态 切换 到 用 户 态 时 ， 执 行 的 第 一 条 指令 并 不 在 应 用 的 二 进 制 镜像 里 起 始 地 址 ， 而 是 动态 
加 载 器 的 始 地 址 ， 代 码 如 下 : 

_start:// 用 户 态 的 第 一 条 指令 

mov r0，sp // 内 核 给 攒 用 户 栈 ， 里 面 放 着 启动 参数 


mov rl, #0 


bl ”linker init //Linker 的 主体 ， 这 里 完成 动态 库 的 逐 级 解析 、 加 载 工作 
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/* linker init returns the entry address in the main image */ 


/*Linker 会 找到 二 进 制 应 用 入 口 点 ， 并 将 其 放 在 0， 下 一 步 就 是 跳 到 二 进 制 应 用 入 口 点 */ 


mov pc, r0 


15.2 ”Linker 主体 


link_image 


Linker 的 主体 是 一 级 级 对 ELF 文件 解析 其 依赖 的 动态 库 并 链接 。 
(1) 第 一 级 : 加 载 需要 的 动态 库 ， 并 将 该 ELF 镜像 链接 上 去 。 


/ /参数 soinfo *si 是 对 这 个 需要 链接 动态 库 的 ELF 文件 的 描述 
static int link image (soinfo *si, unsigned wr offset) 


t 


/* if this is the main executable, then load all of the preloads now */ 
// LD_PRELOAD 的 处 理 ， 这 里 不 讨论 
if(si->flags & FLAG EXE) { 
int 4 
memset (preloads, 0, sizeof (preloads)); 
for(i = 0; ldpreload names[i] != NULL; i++) { 
soinfo *lsi = find library(ldpreload names[i]); 


} 
} 
// 依 次 从 ELF 里 找 出 需要 动态 加 载 动态 库 ， 并 逐一 加 载 


for(d = si->dynamic; *d; d += 2) { 
/*si->strtab + d[1] 就 是 动态 库 的 文件 名 ， 以 /system/bin/app_process 为 例 ， 
这 里 会 解析 出 所 依赖 的 动态 库 如 下 : 1iblog.so、libbinder.so、libandroid_ 
runtime.so、libc.so、1libstdc++.so、1ibm.so。Linker 会 去 默认 的 /vendor/ 
lib、/system/1ib 两 个 目录 下 寻找 这 些 库 */ 
if(d[0] == DT_NEEDED) { 
// 寻 找 需 要 的 动态 库 ， 并 加 载 之 


soinfo *lsi = find library(si->strtab + d[1]); 


// 真 正 的 链接 在 这 里 进行 
if(si->plt ral}) { 
if(reloc library(si, si->plt rel, si->plt rel count)) 
goto fail; 
} 
if(si->rel) { 
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if(reloc library(si, si->rel, si->rel count)) 


goto fail; 


} 


(2) 第 二 级 : 在 已 加 载 库 里 检查 需要 的 动态 库 时 已 经 加 载 并 链接 ， 否 则 将 加 载 、 链 接 
该 动态 库 。 
soinfo *find library(const char *name) 


{ 
// 已 加 载 、 链 接 的 动态 库 都 放 在 solist 链表 里 


for(si = solist; si != 0; si = si->next){ 


if(!strcmp (bname, si->name)) { 
SOLiSt 
// 该 库 已 加 载 并 链接 ， 直 接 返 回 即 可 
if (si->flags & FLAG LINKED) return si; 


} 
| 
// 该 库 已 并 未 涉及 ， 加 载 链接 之 


si = load library (name); 


/* 该 动态 库 已 经 被 加 载 ， 下 一 步 要 检查 该 动态 库 本 身 是 否 依 赖 其 他 动态 库 ， 如 果 存 在 依赖 则 递归 
进去 为 该 动态 库 加 载 其 依赖 的 动态 库 */ 
return init library(si); 


} 


不 由 得 哆 嗪 一 句 : 这 里 对 solist 链表 的 操作 没有 任何 互 斥 操 作 ， 其 原因 在 于 ， 这 时 进 
程 是 独立 的 ， 且 是 单线 程 。 


// 加 载 动态 库 所 依赖 的 动态 库 
static soinfo *init library(soinfo *si) 


{ 


/ /递归 加 载 从 这 里 进去 
if(link image(si, wr offset)) { 
/* We failed to link. However, we can only restore libbase 
** if no additional libraries have moved it since we updated it. 
*y 
munmap ( (void *) si->base, si->size); 


return NULL; 


return si; 
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(3) 第 三 级 : 加 载 动态 库 。 


static soinfo * 


load library(const char *name) 


{ 
// 打 开 该 动态 库 文件 


int fd = open library (name); 


// 给 该 动态 库 分 配 管理 结构 并 加 入 soli st 链表 


si = alloc info(bname ? bname + 1 : name) 7 


/* Now actually load the library's segments into right places in memory 
*/ 
// 具 体 对 动态 库 文 件 的 加 载 操作 ， 把 每 个 PT_LORD 类 型 的 段 MAP 出 来 
if (load segments(fd, & header[0], si) < 0) { 
goto fail; 
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16.1 Android 人 口 


本 节 从 进程 角度 上 分 析 如 何 从 Init 进程 跑 到 ZygoteInitmain (String argv[])。 

首先 作为 用 户 态 的 第 一 个 线程 ，Init 是 被 内 核 加 载 的 ， 对 于 Android 系统 即 为 /init， 参 
见 内 核 部 分 的 rootfs。Init 进程 第 一 件 工 作 是 执行 由 initrc 里 列 出 的 命令 。 根 据 initrc 里 的 
指令 ，Init 进程 要 启动 如 下 service: 


service zygote /system/bin/app process -Xzygote /system/bin --zygote -- 
start-system-server 

socket zygote stream 666 

onrestart write /sys/android power/request state wake 

onrestart write /sys/power/state on 

onrestart restart media 


该 service 其 实 就 是 位 于 /system/bin/app_process 的 进程 ， 其 入 口 函数 源码 所 在 文件 在 


frameworks/base/cmds/app_process/app_main.cpp。 


int main(int argc, const char* const argv[]) 


{ 


/*class AndroidRuntime 实际 上 被 每 个 dvm 进程 所 使 用 ， 但 是 其 初始 化 只 在 这 里 进行 。 
每 个 dvm 进程 是 被 fork () 出 来 ， 所 以 可 以 继续 使 用 其 父 进 程 的 Runtime 实例 。 而 初始 化 只 
在 这 里 进行 一 次 。 而 class AppRuntime 继承 自 AndroidRuntime， 其 初始 化 函数 里 将 进 
行 skia 图 形 相 关 初 始 化 */ 

AppRuntime runtime; 

const char *arg; 


// Next arg is startup classname or "--zygote" 
站 {<arge) { 
arg = argv[i++]; 
/* 根 据 init .rc 的 启动 参数 : --zygote --start-system-server*/ 


if (0 == strcmp("--zygote", arg)) { 
// 条 件 成 立 
bool startSystemServer = (i < argc) ? 


strcmp(argv[i], "--start-system-server") = 一 : false; 
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setArgv0 (argv0, "zygote") 7 
//app_process 就 是 zygote 
set process name ("zygote"); 


/*com.android.internal.os.ZygoteInit 是 Zygote 进程 演化 为 dvm 的 入 口 ，Zygote 还 
有 一 个 任务 是 启动 SystemServer*/ 


runtime.start ("com.android.internal.os.ZygoteInit", 
startSystemServer); 
} else { 


/*Android 运行 时 */ 
void AndroidRuntime::start (const char* className, const bool startSystemServer) 


{ 
/ /初始化 dvm 的 运行 环境 
if (startVm(g&mJavaVM, genv) != 0) 
goto bail; 
// 找 到 需要 执行 的 class: com.android.internal.os.ZygoteInit 
startClass = env->FindClass (slashClassName); 
if (startClass == NULL) { 
} else { 
// 找 到 com.android.internal.os.ZygoteInit 的 main 函数 
startMeth = env->GetStaticMethodID(startClass, "main", 
"([Ljava/lang/Sstring;)V"); 
if (startMeth == NULL) { 
LOGE ("JavaVM unable to find main() in ‘'%s'\n", className); 
/*keep going*/ 
} else { 
/*com.android.internal.os.ZygoteInit 的 main 函数 是 dvm 世界 的 入 口 */ 
env->CallSstaticVoidMethod(startClass, startMeth, strArray); 
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16.2 ”Init 一 OS 的 人 口 


Init 进程 是 第 一 个 用 户 态 进程 ， 是 操作 系统 的 入 口 。Init 进程 在 不 同 的 OS 里 有 不 同 的 
实现 ， 其 主要 工作 是 根据 RC 文件 的 指示 工作 ， 完 成 系统 初始 化 。 


16.2.1 RC 文件 分 析 


RC 文件 是 一 种 脚本 文件 ， 里 面 记录 了 启动 操作 系统 各 组 件 的 动作 。 针 对 于 不 同 的 系 
统 配 置 ，RC 文件 有 着 不 同 的 内 容 ， 但 通常 是 将 硬件 基础 设施 构建 完成 之 后 ， 启 动 Android 
的 系统 服务 。 从 结构 来 看 RC 文件 为 两 级 结构 。 
(1) 第 一 级 是 section，section 有 以 下 三 类 。 
@ 以 on 开头 的 section， 这 个 section 里 会 执行 一 系列 命令 。 
@ 以 service 开头 的 section， 这 个 section 指定 一 个 service 及 其 相关 参数 。 
@ 以 import 开头 的 section。 
(2) 第 二 级 是 针对 于 每 个 section 动作 和 参数 。 
Init 对 RC 分 析 的 主要 工作 如 下 : 
static void parse_config(const char *fn, char *s) 
{ 
for (;;) { 
Switch (next token(&state)) { 
case T_ EOF: 
oa SG Lineteatate, O05 和 让 过 
return; 
case T_NEWLINE: /* 遇 到 了 新 的 一 行 , 现在 处 理 上 一 行 , 上 一 行 分 析 结 果 都 位 于 args[] 
数组 中 */ 
if (nargs) { 
int kw = lookup_keyword (args[0]); /* 首 先 去 看 这 一 行 打头 的 关键 字 是 


什么 */ 
if (kw_is (kw，SECTION) ) { /* 如 果 一 行 以 on 或 service,import 打头 ， 
该 表达 式 为 真 */ 


state.parse line(&state, 0, 0); 
/* 这 里 分 析 一 级 语句 的 类 型 ， 如 果 是 on，section， 就 用 static void parse line 
service(…) 来 分 析 这 一 section; 如 果 是 service，section 就 用 static void 
parse line action(**) 来 分 析 这 一 section*/ 
parse new section(&state, kw, nargs, args); 
} else { 
/* 分 析 二 级 语句 的 具体 的 命令 和 参数 ， 二 级 语句 的 关键 字 和 参数 在 这 之 前 都 被 放 入 args 数组 中 了 */ 
state.parse line(&state, nargs, args); 
} 


nargs = 0; 
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} 
break; 
case T_TEXT: 


/* 对 于 一 、 二 级 语句 行 ， 这 里 分 析 关 键 字 及 其 后 面 的 文本 参数 ， 每 遇 到 关键 字 和 参数 都 会 走 到 这 里 
一 次 ， 作 为 结果 ， 每 个 关键 字 和 参数 都 被 放 到 args [] 数组 里 */ 


if (nargs < SVC MAXARGS) { 
args[nargs++] = state.text; 


} 
break; 


void parse new section(struct parse state *state, int kw, 
int nargs, char **args) 


switch(kw) { 
case K_service: //section 为 service 
state->context = parse service(state, nargs，args);// 分 析 该 service 


if (state->context) { 
// 对 service 的 每 个 属性 行 用 static void parse line service (…) 函数 分 析 
state->parse line = parse line service; 
return; 


; 
break; 
case K_on: //section 为 on 
state->context = parse action(state, nargs，args); // 对 on 进行 分 析 


if (state->context) { 
// 对 on section 里 的 每 个 命令 行 用 static void parse_line_action(…) 函数 分 析 
state->parse line = parse line action; 
return; 


break; 


} 
state->parse line = parse line no op; 
} 


(3) 分 析 service。 
Service 的 基本 结构 如 下 : 


struct service { 


/* 所 有 的 service 穿 成 一 个 以 service 1ist 为 首 的 链表 */ 
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struct listnode slist; 

// 该 service 的 名 称 

const char *name; 

/* 该 service 所 属 的 classname，init 进程 会 依据 不 同 的 classname 启动 与 该 
classname 匹配 的 所 有 service 一 一 void service for each _ class (…)*/ 

Const char *classname; 

/该 service 的 flag 标志 , init 进程 会 依据 不 同 的 标志 启动 与 该 标志 匹配 的 所 有 service 
一 一 void service for each flags (…)*/ 


unsigned flags; 


// 在 restart 时 ， 该 service 执行 的 action， 由 多 个 命令 组 成 


struct action onrestart; /*Rctions to execute on restart*/ 


/*keycodes for triggering this service via /dev/keychord*/ 


} 


static void *parse service(struct parse state *state, int nargs, char **args) 


下 


svc = calloc(1，sizeof(*svc) + sizeof (char*) * nargs);/* 创 建 一 个 struct 
service 结构 来 表示 该 service*/ 

svc->name = args[1];// 该 service 的 名 字 

/*classname 默认 值 为 default， 在 分 析 该 service 组 成 语句 时 会 填充 该 值 */ 
svc->classname = "default"; 

memcpy (svc->args，args + 2，sizeof (char*) * nargs);// 保 存 service 的 参数 
svc->args[nargs] = 0; 

svc->nargs = nargs; 

svc->onrestart.name = "onrestart"; 

// 初 始 化 onstart action 的 命令 行 链表 

list init(&svc->onrestart.commands); 

// 将 该 service 加 到 系统 的 service 链表 中 

list add tail(&service list, &svc->slist); 

return svc; 


} 
对 于 serice 下 面 的 每 一 个 属性 行 ， 都 用 static void parse_line_service(…) 来 分 析 ， 这 个 
函数 很 长 ， 其 骨架 结构 如 下 : 


static void parse line service (struct parse state *state, int nargs, char 
**args) 


t 


kw = lookup keyword(args[0]); // 找 出 关键 字 


292 拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 


Switch (kw) { 
case K class: // 是 否 显 式 指定 classname 
if (nargs != 2) { 
parse error (state, "class option requires a classname\n"); 
} else { 
svc->classname = args[1]; // 保 存 指定 classname 


} 


break; 

case K disabled: // 是 否 默 认为 disable 状态 
svc->flags 1= SVC_DISABLED; // 设 置 禁止 flag 
break; 

case K_oneshot: // 是 否 为 oneshot 模式 
svc->flags |= SVC_ONESHOT;  // 设 置 oneshot flag 
break; 


case K_ onrestart: 

/* 分 析 某 service 对 应 的 onrestart 动作 ， 以 Zygote 为 例 ， 该 service 对 于 多 个 
onrestart 动作 : 
service zygote… 


每 个 onrestart 动作 都 对 应 一 个 命令 
onrestart write /sys/android power/request state wake 
onrestart write /sys/power/state on 
onrestart restart surfaceflinger 
onrestart restart media 
onrestart restart netd 
所 有 命令 都 搜集 起 来 ， 作 为 onrestart action 的 命令 列表 
wh 
nargs-——; 
argS++7 
// 提 取 命令 类 型 
kw = lookup keyword(args[0]); 
// 分 配 命令 结构 
cmd = malloc(sizeof (*cmd) + sizeof(char*) * nargs); 
// 提 取 命令 动作 函数 
cmd->func = kw_func (kw) 
cmd->nargs = nargs; 
// 存 储 命令 参数 
memcpy (cmd->args, args, sizeof (char*) * nargs) 7 
// 加 入 onrestart action 命令 链表 
list adqd taill(&svc->onrestart.commands, &cmd->clist); 


break; 
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(4)“on”section 的 分 析 。 
每 个 “on ”section 表示 在 某 个 时 刻 触发 一 系列 动作 ， 其 基本 结构 如 下 : 


struct action { 
/* 所 有 的 action 穿 成 以 action list 为 首 的 链表 */ 
struct listnode alist; 
/* 以 action queue 为 首 的 链表 记录 了 即将 被 init 执行 的 action 动作 链表 ，qlist 是 这 
个 链表 的 节点 */ 


struct listnode qlist; 


// 该 action 对 应 的 命令 链表 
struct listnode commands; 
// 指 向 当前 命令 
struct command *current; 


}; 


static void *parse action(struct parse state *state, int nargs, char **args) 


{ 


act =calloc(1, sizeof (*act));// 对 于 每 个 on, section 都 生成 一 个 struct action 
act->name = args[1]; // 这 里 的 args[1] 就 是 on 的 触发 条 件 ， 如 init、boot 等 
list init(g&act->commands); 

list add tail (gaction list，&act->alist);/* 并 将 这 个 struct action 加 入 系 
统 的 action_1ist 链表 */ 


return act; 


} 


对 于 每 个 on，section 里 的 命令 都 生成 一 个 struct command 结构 ， 并 将 这 个 结构 加 入 在 
struct action 的 commands 列表 中 。 
On section 的 二 级 语句 分 析 如 下 : 


static void parse line action(struct parse state* state, int nargs, char 
**args) 


{ 


kw = lookup_keyword (args[0]); ”// 找 到 命令 对 应 的 关键 字 


cmd = malloc (sizeof (*cmd) + sizeof (char*) * nargs); 
cmd->func = kw func (kw); // 找 到 每 个 命令 对 应 的 执行 函数 
cmd->nargs = nargs; 

memcpy (cmd->args, args, sizeof (char*) * nargs); 


list adqd tail(&act->commands， &cmd->clist); 
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} 
分 析出 来 的 on section 被 放 入 action list 链表 中 。 


16.2.2 ”RC 动作 执行 


RC 定义 的 动作 和 service 分 析 后 都 被 放 到 action list 链表 和 service_list 链表 中 。 

(1) On section 动作 的 执行 。 

每 个 on section 都 有 着 自己 的 执行 时 机 ，on 之 后 的 字符 串 指出 了 该 action 在 合适 时 被 
执行 。 在 init 进程 完成 对 RC 文件 的 分 析 之 后 调用 action for each trigger("XXX"，action 
add_ queue tail); 将 不 同 执行 时 机 的 action 加 入 action 的 执行 链表 action_ queue。 接 着 init 的 
主 循环 中 依次 触发 每 个 action。Init 进程 执行 action 的 动作 顺序 如 下 : 

"early-init"->"init"->"early-fs"->"fs"->"post-fs"->"post-fs-data"->"early-boot"->"boot" 

除了 在 RC 文件 里 定义 的 action 之 外 ，Init 还 有 一 些 builtin 的 action，init 使 用 void 
queue_builtin_action(…) 将 其 现在 合适 的 位 置 加 入 action_queue 执行 链表 。 

如 在 触发 时 机 early-init 与 init 之 间 ， 直 接 加 入 如 下 builtin action， 部 分 代码 如 下 : 


| 


// 将 触发 时 机 early-init 的 action 加 入 action_queue 执行 链表 
action for each trigger("early-init", action add queue tail); 

// 如 下 是 init 的 系统 默认 的 builtin action 

queue builtin action(wait for coldboot done action,"wait for_ 

coldboot done"); 

queue builtin action(property init action, "property init"); 

queue builtin action(keychord init action, "keychord init"); 

queue builtin action(console init action, "console init"); 

queue builtin action(set init properties action, "set init properties"); 


/* 将 触发 时 机 "init" 的 action 加 入 action_queue 执行 链表 */ 


action for each trigger("init", action add queue tail); 


} 


(2) Service section 中 service 的 执行 。 

@ 依据 classname 启动 。 

对 于 每 个 service section， 每 个 class 都 会 有 一 个 属性 classname，android 可 以 启动 所 有 
classname 符合 条 件 的 service。 常 见 的 一 个 例子 是 on boot section 里 会 默认 启动 ，classname 
为 core 和 main 的 service: 


在 rc 文件 中 有 如 下 定义 : 


on boot 
class_start core 


class start main 
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而 class_start 命令 对 应 的 执行 函数 为 定义 如 下 (在 system/core/init/keywords.h 中 ): 
KEYWORD (class_ start, COMMAND, 1, do class start) 


int do_class_start(…) 会 依据 classname 启动 对 于 的 service。 
@ 启动 指定 名 字 的 service。 
根据 service 结构 的 成 员 变 量 const char *name; 来 启动 某 个 特定 的 service， 这 种 方式 常 


用 在 RC 文件 里 通过 命令 启动 启动 某 个 service， 如 在 RC 文件 中 有 如 下 定义 : 


on property:persist.service.adb.enable=1 
start adbd 


而 start 命令 对 应 的 执行 函数 为 定义 如 下 (在 system/core/init/keywords.h 中 ): 
KEYWORD (start, COMMAND, 1, do start) 


int do_start(…) 函 数 会 启动 名 为 adbd 的 service。 
@ 以 某 个 标志 位 启动 service。 
启动 标志 位 为 SVC_RESTARTING 的 service。 


static void restart processes() 
{ 
process needs restart = 0; 
service for each flags (SVC RESTARTING, 
restart service if needed); 


} 


16.2.3 ”RC 的 逻辑 分 析 


的 


o 


RC 文件 虽然 只 是 脚本 文件 , 但 是 控制 着 整个 Android 系统 的 启动 , 所 以 还 是 值得 一 读 
RC 文件 分 析 依 据 的 脉络 是 几 个 主要 的 启动 时 机 : 
early-init—init—early-fs—fs—post-fs—post-fs-data— early-boot— boot 

(1) early-init。 启 动 ueventd， 设 备 管理 的 基础 ， 见 下 文 分 析 。 

(2) init。 时 间 设 置 ， 设 置 环境 变量 ， 创 建 基 本 目录 。 

(3) ff。 通常 与 具体 的 硬件 平台 有 关 ， 这 里 mount 上 /system、/data。 

(4) post-fs。 某 些 目 录 权限 的 修改 。 

(5) post-fs-data。/data 下 某 些 目录 的 创建 。 

(6) boot。 网 络 、 蓝 牙 、alsa、iil 等 设备 的 属性 设置 ， 启 动 core 和 main 之 类 的 sevice。 


16.2.4 设备 探测 


Android 利用 Linux 的 uevent 探测 系统 中 的 设备 ， 再 根据 动态 探测 到 设备 信息 动态 创 


建 /dev 下 的 设备 文件 ， 代 码 如 下 : 
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int device _ init (void) 
{ 
fd = open uevent socket (); // 首 先 建立 与 内 核 的 联系 管道 :通过 NETLINK 


coldboot (fd，"/sys/class") ; // 扫 描 以 下 目录 中 的 设备 并 为 其 动态 创建 设备 文件 
coldboot (fd, "/sys/block"); 
coldboot (fd, "/sys/devices"); 


} 


这 里 有 两 个 层次 的 动作 ,首先 建立 起 与 内 核 uevent 机 制 的 联系 ， 内 核 uevent 机 制 通过 
两 种 方式 与 用 户 态 沟 通 : /sbin/hotplug 和 NETLINK。 

/sbin/hotplug 是 用 户 态 的 一 个 系统 进程 ， 每 当 内 核 触发 一 个 uevent 事件 都 会 把 事件 描 
述 当 作 参 数 ， 启 动 /sbin/hotplug， 而 /sbin/hotplug 启动 后 根据 内 核 传 来 的 参数 分 析 uevent 事 
件 ， 进 而 与 OS 系统 组 件 交互 。Android 体系 抛弃 了 使 用 /sbin/hotplug 的 方式 ， 而 依赖 与 
NETLINK 取得 uevent 消息 。 


static void do_coldboot (int event fd, DIR *d) 
{ 


fd = openat (dfd，"uevent"，0O_WRONLY) ;// 打 开 该 目录 下 的 uevent 文件 
if(fd >= 0) { 
write (fd，"add\n"，4); // 向 该 uevent 文件 写 入 add 
close (fd) ， 
handle_device fd(event fd);/* 由 于 激活 了 uevent 文件 的 add 动作 ， 下 面 可 以 
从 NETLINK 取 uevent 信息 了 */ 
} 
// 接 下 来 在 该 目录 下 寻找 目录 项 
while((de = readdir(d))) { 
DIR *d22> 


if(de->d type != DT DIR || de->d_name[0] == '.') 
continue; // 不 是 目录 文件 ， 绕 过 


fd = openat (dfd，de->qd name，0O_RDONLY | 0_DIRECTORY) ; // 新 发 现 一 个 目录 
d2 = fdopendir (fd); 


do_coldboot (event fd，q2);/* 递 归 进入 这 个 目录 ， 再 次 寻找 这 个 目录 下 的 
uevent 文件 


} 


这 个 函数 的 主要 动作 就 是 到 一 个 目录 下 找 uevent 文件 ， 并 通过 向 这 个 文件 写 入 add 激 
活 其 uevent 的 信息 ， 然 后 通过 void handle_device fd(…) 从 NETLINK 获得 uevent 描述 ， 再 
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根据 获得 的 设备 信息 动态 创建 /dev 下 的 设备 文件 /dev 创建 的 具体 执行 过 程 如 图 16-1 所 示 。 


void handle_ device fd(*…)-> static void handle device_event(…)-> void make device(*…) 


static void ssize trecv(...) 从 NETLINK 取信 息 


static void parse_event(...) uevent 信息 分 析 


void handle_device fd(...) 


static void handle device event((...) 构 建 /dev 
各 级 目录 


static void make device(〔(...) 构建 
/dev 各 级 目录 下 各 个 设备 节点 


图 16-1 /dev 创建 的 具体 执行 过 程 


隐藏 在 这 之 下 的 内 核 机 制 如 下 。 

(1) 每 当 驱 动向 内 核 注册 一 个 设备 ， 那 么 内 核 为 其 在 sysfs 文件 系统 里 创建 一 个 目录 。 

(2) 内 核 在 该 设备 对 应 目录 下 放置 一 个 uevent 文件 ， 而 这 个 文件 写 函 数 ， 会 触发 
uevent。 

(3) 当 用 户 态 往 这 个 设备 目录 下 的 uevent 文件 写 入 add 动作 时 ， 该 文件 下 的 函数 被 触 
发 ， 进 而 触发 内 核 的 uevent 机 制 。 

(4) 内 核 uevent 机 制 向 NETLINK 写 入 设备 的 信息 。 

(5) Android 用 户 态 从 NETLINK 取出 设备 信息 。 


16.2.5 ”property 库 的 构建 


Android 把 系统 的 属性 值 统一 存放 在 property 库 ，Android 系统 其 他 组 件 通 过 int 
property_set(…) 来 设置 相关 属性 值 ， 而 通过 int property_get(…) 来 获取 相关 属性 值 。 

关于 property 库 的 构建 有 如 下 几 个 方面 的 内 容 。 

(1) init 进程 调用 void property_init(…) 建 立 存放 property 值 的 内 存 区 域 ， 并 将 系统 中 
默认 的 property 配置 文件 /defaultprop 加 载 到 内 存 中 。 

(2) RC 文件 以 及 Init 进程 中 动态 设置 系统 property。 

(3) Init 进程 在 post-fs-data 与 early-boot 中 间 ， 调 用 queue_builtin action(property_ 
service_init_action, "property_service_init"); 将 property 初始 化 的 builtin action 加 入 运行 队列 。 
该 action 将 系统 文件 /system/build.prop、/system/default.jprop、/data/local.prop 里 的 property 
值 加 载 入 内 存 。 而 更 为 重要 的 是 ，Init 进程 创建 一 个 PF_UNIX 域 的 进程 间 通 信 socket， 以 
后 Android 其 他 组 件 〈 由 于 与 Init 进程 不 在 同一 进程 空间 ) 就 通过 这 个 socket 机 制 来 查询 
和 更 新 property 库 。 


298 拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 


另 一 个 值得 关注 的 地 方 是 ， 某 个 property 改变 而 将 会 导致 系统 触发 一 系列 的 动作 ， 这 
种 类 型 的 property 在 RC 文件 被 当成 一 个 on section 被 定义 ， 代 码 如 下 : 


on property:vold.decrypt=trigger restart framework 
class_ start main 


class start late start 


Android 运行 时 ， 每 当 这 种 property 值 发 生 改变 ，action_list 里 每 一 项 都 受到 检查 ， 如 
果 发 现 该 项 的 触发 条 件 恰好 是 property 值 ， 那 么 该 section 将 被 触发 。 
void property changed(const char *name, const char *value) 
{ 
if (property triggers enabled) {//init 启动 后 property triggers enabled 
被 置 1 
// 检 查 与 property 值 相关 的 action 
queue property triggers (name, value); 
} 
} 
Void queue property triggers(const char *name, const char *value) 
{ 
struct listnode *node; 
struct action *act; 
list_for each(node，&action 1ist) {// 裔 历 action list 链表 
// 取 出 每 个 action 
act = node to item(node, struct action, alist); 
// 检 查 该 action 是 否 由 property 触发 
if (!strncmp (act->name， "property:", strlen("property:"))) { 
const char *test = act->name + strlen("property:"); 
int name length = strlen (name); 
// 检 查 property 的 属性 名 


if (!strncmp (name, test, name length) && 


test[name length] == '=' && 

!strcmp (test + name length + 1, value)) { 
// 加 入 action 触发 执行 队列 
action add queue tail(act); } 


} 
另外 ， 在 RC boot 阶段 之 后 ，Init 进程 会 显 式 的 调用 : 


queue builtin action(queue property triggers action, "queue propetry_ 


triggers"); 

比较 该 系统 中 的 property 值 是 否 为 RC 文件 中 “=” 赋 予 的 值 ， 如 不 相等 将 该 action 加 
入 执行 队列 。 

接 下 来 Init 完成 以 下 工作 后 进入 主 循环 。 
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(1) Init 进程 调用 load 565rle image(…)， 将 /initlogo.rle 显示 在 屏幕 上 。 这 里 没什么 好 
说 的 ， 就 是 map 出 framebuffer， 然 后 把 图 贴 上 去 。 

(2) 把 触发 条 件 为 init、early-boot、boot 的 section 执行 掉 ， 这 将 导致 大 量 property 值 
被 设置 。 

(3) 把 触发 条 件 为 property 等 于 某 个 值 的 section 执行 掉 。 


16.2.6 Init 的 调试 


Init 进程 的 信息 输出 并 没有 使 用 Android 系统 下 常用 的 LOG 输出 功能 。Init 进程 的 信 
息 输出 自 成 一 套 ，Init 信息 的 出 口 是 /dev/kmsg。 在 Init 进程 时 错误、 警告 、 调 试 等 信息 输 
出 的 工具 如 下 : 

#define ERROR (x…) log write(3, "<3>init: " x) 

#define NOTICE(x..) log write(5, "<5>init: " x) 

#define INFO (x...) log write(6, "<6>init: " x) 


但 是 在 Init 进程 通过 INFO 和 NOTICE 输出 调试 信息 的 时 候 却 什么 也 得 不 到 。 输 出 的 
信息 为 什么 会 丢失 ? 进一步 分 析 void log_write(…): 
void log writel(int level, const char *fmt, ...) 


{ 


/* 这 里 是 在 init 进程 里 通过 INFO 和 NOTICE 都 无 法 调试 输出 的 原因 ，Rndroid 系统 中 
1og_level 为 默认 值 4， 所 以 这 里 就 返回 了 */ 

if (level > log level) return; 

// 如 果 没 有 log_fd 文件 ， 依 然 返 回 

if (log fd < 0) return; 


// 把 内 容 全 都 写 入 log_fd 文 件 
write (1og_fd，buf，strlen (buf) ) 
} 


我 们 发 现 信 息 的 输出 通过 写 log fa 这 个 文件 来 实现 。 那 么 log_fd 是 什么 文件 ， 在 哪里 
打开 呢 ? Init 的 main 函数 里 会 调用 void log_init(void) 函 数 来 初始 化 自己 的 LOG 文件 。 


void log_init (void) 
{ 
if (mknod(name, S_IFCHR | 0600，(1 << 8) | 11) == 0) { /* 创 建 主 设备 号 为 1、 
次 设备 号 为 11 的 字符 文件 */ 
log_fd = open (name，O_WRONLY) ;// 以 只 写 方式 打开 log_fd 文 件 
se 
} 


可 见 log_f4 文件 对 应 的 是 Linux 系统 中 主 设备 号 为 1、 次 设备 号 为 11 的 字符 文件 是 
/dev/kmsg， 其 实现 位 于 内 核 源码 树 下 drivers/char/mem.c 文件 。 这 个 文件 是 内 存 文 件 ， 即 不 
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存在 于 nand 或 磁盘 ， 只 是 内 核 运行 时 虚拟 的 一 个 设备 文件 ， 其 驱动 实现 如 下 : 
static const struct file operations kmsg fops = { 
.write = kmsg write, 


}; 


static ssize t kmsg write (struct file * file, const char user * buf, 


size t count, loff t *ppos) 


tmp = kmalloc(count + 1，GFP_KERNEL); // 在 内 核 空间 分 配 一 块 内 存 


if (!copy_from user (tmp，buf，count)) {// 将 用 户 空间 的 内 存 复 制 到 内 核 


tmp[count] = 0; 
ret = printk("%s", tmp); // 把 取 到 内 容 打出 来 


] 
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解释 器 是 影响 虚拟 机 性 能 关键 因素 ,最初 的 Dalvik 只 有 C 语言 版 本 的 解释 器 ,到 汇编 
实现 的 ASM 解释 器 ， 再 到 进一步 将 JIT 做 进 解释 器 。 在 每 一 代 Android 版 本 的 release 中 ， 
都 将 提升 Dalvik 解释 器 的 效率 作为 重要 工作 。 


17.1 解释 器 编译 结构 


对 于 不 同 的 处 理 器 和 指令 集 ,Android 有 着 与 之 对 应 的 高 度 优化 Interpreter 和 JIT 实现 。 
为 了 支持 这 些 不 同 的 架构 处 理 器 和 指令 集 ，Android 使 用 了 灵活 的 编译 结构 。 

(1) 在 dalvik/vm/Android.mk 里 包含 ReconfigureDvm.mk。 

(2) 在 ReconfigureDvm.mk 里 包含 Dvm.mk。 

(3) dalvik/vm/Dvm.mk 是 悬 着 指令 集 的 关键 ， 这 里 根据 环境 变量 dvm_arch_variant 选 
择 指令 集 的 对 应 实现 。 

对 于 集成 NEON 的 arm 处 理 器 ， 对 应 的 两 个 最 关键 的 实现 文件 是 InterpAsm- 


armv7-a-neon.S 和 InterpC-armv7-a-neon.cpp。 


mterp/out/InterpC-$ (dvm_arch_variant) .cpp.arm \ 
mterp/out/InterpAsm-$ (dvm arch variant).s 


makefile 里 的 包含 的 源 文件 是 InterpC-armv7-a-neon.cpp.arm， 实 际 上 没有 这 个 文件 ， 
在 build/core/binarymk 里 面 对 cpp_arm sources 有 着 特殊 的 编译 处 理 。InterpC-armv7 
-a-neon.cpp.arm 对 应 的 就 是 InterpC-armv7-a-neon.cpp。 


17.2 Dalvik 寄存 器 编译 模型 


Dalvik 是 基于 寄存 器 的 虚拟 机 ， 其 寄存 器 编译 模型 是 以 函数 为 中 心 的 ， 包 括 函数 内 部 
寄存 器 、 函 数 问 调用 时 参数 寄存 器 与 结果 寄存 器 的 分 配 与 布局 。 


17.2.1 Callee 寄存 器 分 配 
Dalvik 的 Callee 函数 寄存 器 分 配 规 则 如 下 : 


对 于 没有 产生 调用 的 函数 : 
(1) 设 函 数 定义 的 局 部 变量 为 n 则 寄存 器 0 一 一 寄存 器 (n-1) 被 依次 分 配给 局 部 变量 。 
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(2) 寄存 器 n 被 分 配给 this。 
(3) 设 函 数 参数 为 m， 则 寄存 器 (n+1) 一 一 寄存 器 Cntm) 被 依次 分 配给 局 部 变量 。 
(4) 如 果 函 数 运算 过 程 中 使 用 了 中 间 变 量 ， 则 为 中 间 变 量 分 配 寄存 器 ， 寄 存 器 号 插入 
在 this 寄存 器 的 后 面 。 
以 如 下 函数 为 例 : 
public int senix register (int parl,int par2,int par3) { 
int local varl=1; 
int Doanl are 
local varl=local varl+local var2tparltpar2+par2; 


return local varl; 


} 
使 用 ./out/host/linux-x86/bin/dexdump -d ”.odex 将 字 节 码 输出 : 


name :'senix_register' // 函 数 名 

type : "(III)I'// 三 个 int 参数 ， 返 回 值 也 为 int 
access : 0x0001 (PUBLIC) // 属 性 
code = 
registers : 7 // 共 用 了 7 个 寄存 器 
ins : 4 // 输 入 变量 
outs : 0// 没 有 调用 其 他 函数 outs 为 0 
insns size : 8 16bit code units 

064efc: 1[064efc] 


com.android.launcher2.LauncherApplication.senix register: (III)I 

064f0c: 1210 10000: const/4 v0, #int 1 // #1 /*local varl=1;*/ 

064f0e: 1221 10001: const/4 v1, #int 2 // #2 /*local var2=2;*/ 

064f10: d802 0403 10002: add-int/lit8 v2, v4, #int 3 // #03 /*local varl 
+local_var2 被 优化 掉 成 操作 数 #int 3, 分 配 一 个 寄存 器 v2 放置 中 间 结 果 , 这 里 实际 效果 是 v2= 
local varltlocal var2+parl*/ 

064f14: b052 10004: add-int/2addr v2, v5 /* v2= local varl+tlocal var2+ 
parl+par2 */ 

064f16: 9000 0205 10005: add-int v0, v2, v5 /* v2= local varltlocal var2+ 
parl+par2+par1， 并 且 把 结果 放 到 寄存 器 v0 中 */ 


064fla: 0f00 10007: return v0 /* 以 v0 返回 结果 */ 
catches : (none) 
positions 


0x0000 line=78 
0x0001 line=79 
0x0002 line=80 
0x0007 line=81 
locals : 
0x0001 - 0x0008 reg=0 local varl I // 寄 存 器 0 分 配给 local varl 
0x0002 - 0x0008 reg=1 local var2 I // 寄 存 器 1 分 配给 local var2 
0x0000 - 0x0008 reg=3 this Lcom/android/launcher2/Launcher 
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Application; /* 寄 存 器 3 存放 类 对 象 this， 该 函数 是 在 class LauncherRpp1lication 里 
添加 的 */ 

0x0000 - 0x0008 reg=4 parl I // 寄 存 器 4 分 配给 输入 参数 par4 

0x0000 - 0x0008 reg=5 par2 I // 寄 存 器 5 分 配给 输入 参数 par5 

0x0000 - 0x0008 reg=6 par3 I // 寄 存 器 6 分 配给 输入 参数 par5 


17.2.2 Caller 寄存 器 分 配 


Caller 函数 的 寄存 器 分 配 规则 是 ， 首 先 满足 Callee 函数 的 寄存 器 分 配 规则 ， 但 是 在 此 
规则 之 外 , 产生 调用 时 , 要 在 Callee 函数 帧 的 高 地 址 放 入 调用 参数 。 这些 调用 参数 被 Callee 
当成 ins。 

以 如 下 函数 为 例 分 析 : 


public int senix registerl(int parl,int par2,int par3) { 
int local varl=1; 
int local var2=2; 
local varl=local varltlocal var2+tparltpar2+par2; 

return local varl; 
} 
public int senix register callerl(int parl,int par2,int par3) { 
int local varl=1; 
int local var2=senix register(4,5,6); 
local varl=local varl+tlocal var2+parltpar2t+par2; 
return local varl; 


} 


senix_register_caller(int parl,int par2,int par3)dump 的 结果 如 下 : 


name : 'senix register_caller' 

type 下 

access : 0x0001 (PUBLIC) 

code 二 

registers : 9 // 共 用 了 9 个 寄存 器 

ins : 4//3 个 输入 参数 +this，this 不 占 寄存 器 

outs : 4//3 个 输出 参数 +this，this 不 占 寄 存 器 

insns size : 15 16-bit code units|[064f28 
064f28:] 


com.android.launcher2.LauncherApplication.senix register caller: (III)I 
064f38: 1210 |10000: const/4 vo, #int 1 // #1 

064f3a: 1242 10001: const/4 v2，#int 4 // #4 /* 给 参数 4 分 配 寄存 器 2*/ 
064f3c: 1253 10002: const/4 v3，#int 5 // #5 /* 给 参数 4 分配 寄存 器 3*/ 
064f3e: 1264 10003: const/4 v4，#int 6 // #6 /* 给 参数 6 分 配 寄存 器 2*/ 
064f40: £840 7400 2543 10004: +invoke-virtual-quick {v5, v2, v3, v4}, [0074] 
// vtable #0074/* 调用 发 生 了 ，3 个 参数 加 this */ 

064f46: 0a01 10007: move-result v1 /* 把 返回 值 放 到 v1*/ 
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/* 下 面 为 计算 操作 ， 参 见 上 一 节 分 析 */ 


064f48: 9002 0001 10008: add-int v2，V0，v1 
064f4c: b062 1000a: add-int/2addr v2, v6 
064f4e: b072 1000b: add-int/2addr v2, v7 
064f50: 9000 0207 1000c: add-int vO, v2, v7 
064f54: 0f00 1000e: return vO 

catches : (none) 

positions : 


0x0000 line=88 
0x0001 line=89 
0x0008 line=90 
0x000e line=91 
locals s 
0x0001 - 0x000f reg=0 local varl I // 寄 存 器 0 分 配给 local varl 
0x0008 - 0x000f reg=1 local var2 I // 寄 存 器 1 分 配给 local_var2 
0x0000  - 0x000f reg=5 this Lcom/android/launcher2/Launcher 
Application; /* 寄 存 器 5 分 配给 this*/ 
0x0000 - 0x000f reg=6 parl I// 寄 存 器 6 分 配给 parl 
0x0000 - 0x000f reg=7 par2 I// 寄 存 器 7 分 配给 par2 
0x0000 - 0x000f reg=8 par3 I// 寄 存 器 8 分 配给 par3 


寄存 器 v2、v3、Yv4 分 配给 三 个 调用 参数 。 到 了 这 里 还 是 不 能 看 清 这 些 outs 到 底 放 在 
哪里 。 要 解决 这 个 问题 需 分 析 解 释 器 处 理 invokeMethod_XXX 指令 时 是 如 何 安排 参数 的 。 


17.2.3 ”outs 的 处 理 


分 析 outs 的 处 理 离 不 开 对 函数 调用 的 分 析 ， 在 解释 器 遇 到 Dalvik 函数 调用 指令 
invokeMethod 时 ， 其 C 解释 器 handler 如 下 〈 上 文 在 分 析 native 函数 调用 时 遇 到 过 这 个 
handler， 这 里 侧重 分 析 的 寄存 器 布局 ): 


//C 解释 器 的 invokeMethodhandler 
GOTO_TARGET (invokeMethod, bool methodCallRange, const Method* _method 
OCR， 

u2 count, u2 regs) 


§ 


ud* outs; 

kn 评 

/* 首 先 正 如 注释 所 说 ,复制 参数 ， 这 里 分 为 两 种 情况 ， 如 果 一 个 函数 参数 个 数 比 较 多 ， 则 变 
量 methodcallRange 成 帧 。 对 于 每 个 参数 , 都 用 GET_REGISTER 从 当前 函数 帧 里 取 值 ， 
再 复制 给 参数 在 Callee 函数 中 的 寄存 器 */ 


if (methodCallRange) { 
// 在 当前 栈 上 给 参数 分 配 空间 ，vsrcl 就 是 参数 个 数 
outs = OUTS FROM FP(fp, vsrcl1); 


for (= 07 i < vesrcl; it++) 
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outs[i] = GET REGISTER(vdst+i); 
} else { 


u4 count = vsrcl >> 4; 


// 在 当前 栈 上 给 参数 分 配 空间 ，count 就 是 参数 个 数 
outs = OUTS FROM FP(fp, count); 
assert((vdst >> 16) == 0); // 1l6bits -or- high 16bits clear 
switch (count) { 
// 根 据 参 数 个 数 的 不 同 ， 有 着 不 同 的 处 理 
case 5: 
outs[4] = GET REGISTER(vsrcl & Ox0f); 


case 1: 
outs[0] = GET REGISTER(vdst & 0x0f); 
default: 


;7 


} 
在 完成 了 参数 分 配 及 初始 化 之 后 ， 分 析 参 数 空间 的 分 配 OUTS_FROM _FP: 
#define OUTS FROM FP( fp, argCount) \ 


((u4*) ((ul*)SAVEAREA FROM FP( fp) - sizeof(u4) * (_argCount))) 
#define SAVEAREA FROM FP!(_ fp) ((StackSaveArea*) (_fp) -1) 


不 难 发 现 , 不 是 从 当前 帧 指针 _fp 往 下 分 配 , 而 是 越过 StackSaveArea 在 往 下 分 出 空间 。 
这 样 做 的 原因 是 _ 印 指针 是 用 来 索引 寄存 器 ， 而 一 个 函数 帧 里 在 印 往 下 还 存在 着 一 个 
VM-specific internal goop-- struct StackSaveArea。 由 此 可 以 得 出 以 下 结论 。 

(1) outs 其 实 就 是 从 Caller 角度 看 的 调用 参数 ， 就 是 Callee 的 ins。 

(2) outs 到 ins 是 拷贝 ，outs 分 配 的 那些 寄存 器 在 Caller 还 可 作为 他 用 。 


17.3 ”Portable Interpreter 结构 


最 初 的 几 个 Android 版 本 里 , Dalvik 的 解释 器 是 用 C 写 的 。 这 种 解释 器 执行 速度 较 慢 ， 
但 可 读 性 较 强 ， 移 植 性 好 ， 在 以 后 Android 版 本 里 尽管 实现 了 汇编 优化 的 解释 器 ， 但 这 种 
portable 解释 器 依然 存在 。 在 Android 向 某 个 全 新 架构 的 处 理 器 上 移植 时 是 没有 对 应 的 汇编 
解释 器 的 ， 这 时 portable 的 价值 就 体现 出 来 了 。 

该 解释 器 的 核心 是 一 个 handler 数组 ， 其 定义 如 下 : 


#define DEFINE GOTO TABLE( name) \ 
static const void* _name [kNumDalvikInstructions] = { \ 
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H(OP_ MOVE WIDE FROM16), \ 


H(OP_ MOVE OBJECT 16), 

H(OP_ MOVE RESULT), 
H(OP_MOVE RESULT WIDE), 

H(OP_ MOVE RESULT OBJECT), 
H(OP_ MOVE EXCEPTION), 


i 


到 全 


该 数组 handlerTable 存放 着 每 个 操作 码 的 handler 地 址 ,每 遇 到 一 个 操作 码 就 跳 到 这 个 
数组 里 取出 handler 来 执行 该 操作 码 。 而 每 条 操作 码 的 handler 结构 定义 如 下 : 
HRANDLE_OPCODE (OP_XXX) 


FINISH(…) 7 
OP_END 


其 中 HANDLE_ OPCODE(OP _ XXX) 被 定义 成 该 段 handler 标号 , handlerTable 对 应 项 指 
向 这 个 地 址 ， 而 每 个 操作 码 执行 完 ， 都 通过 FINISH(…) 取 出 下 一 个 操作 码 ， 然 后 跳 入 该 操 
作 码 对 应 的 handler 中 。 


# define FINISH( offset) { % 
// 将 PC 指向 下 一 条 字 节 码 
ADJUST PC( offset); 
// 取 出 字 节 人 码 到 inst 
inst = FETCH(0); y 


//INST_INST (inst) 即 为 指令 编号 ， 根 据 这 个 编号 索引 handlerTable 的 位 置 
goto *handlerTable[INST INST (inst)]; % 
} 


其 中 ,ADJUST_PC(_offset) 是 将 操作 码 代 码 段 的 PC 指针 指向 下 一 个 操作 码 , FETCH(0) 
的 作用 是 取出 这 个 操作 码 ， 最 后 跳 入 下 一 个 操作 码 的 handler。 
17.4 ASM Interpreter 


Dalvik 默认 的 解释 器 就 是 这 种 汇编 优化 的 解释 器 ， 根 据 不 同 CPU 架构 有 不 同 的 实现 ， 
本 文 主要 讨论 ARM V7 架构 的 实现 。 


17.4.1 基本 结构 


与 portbale 解释 器 一 样 ，ASM 解释 器 也 是 一 个 由 不 同 字 节 码 解释 器 组 成 的 大 数组 ， 这 
是 ASM Interpreter 的 mainhandler， 在 正常 运行 时 使 用 ， 其 实现 在 文件 dalvik/vm/mterp/ 
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out/InterpAsm-armv7-a-neon.S 中 。 
(1) mainHandler 大 数组 定义 如 下 : 


// 大 数组 的 基地 址 : dvmAsmInstructionStart。 即 为 编号 为 0 的 NOP 指令 的 地 址 
dvmRsmInstructionStart = .L OP NOP 
// 代 码 段 
text 
/* 偏 移 量 64， 每 个 handler 64byte， 不 够 的 话 再 跳 的 其 他 地 方 ， 但 要 保证 每 个 handler 64 
字 节 的 入 口 */ 
-balign 64 
.L_ OP NOP: /* 0x00 */ 
/* File: armv5te/OP NOP.S */ 


//64 字 节 对 齐 ， 第 二 个 字 节 码 MOVE 的 handler 
.balign 64 

.L_ OP MOVE: /* Ox01 */ 

/* File: armv6t2/OP MOVE.S */ 
/* for move, move-object, long-to-int */ 
/* op vA, vB */ 


mov Ely.. FINST, Lsr #12 @ rl<- B from 15:12 

ubfx r0, rINST, #8, #4 @ r0<- A from 11:8 

FETCH ADVANCE INST (1) @ advance rPC, load rINST 
.balign 64 


.Size dvmAsmInstructionStart, .-dvmAsmInstructionstart 
.global dvmAsmInstructionEnd 

//mainhandler 数组 结束 

dvmAsmInstructionEnd: 


对 于 有 些 字 节 码 不 能 用 64 字 节 完成 其 handler 实现 , ASM 解释 器 将 其 余 实 现 放 在 代码 
段 dvmAsmSisterStart 里 。 

(2) ALThandler 

ASM Interpreter 的 还 有 一 个 ALThandler， 在 JIT 和 debugger 时 使 用 ， 其 实现 也 在 文件 
dalvik/vm/mterp/out/InterpAsm-armv7-a-neon.S 中 。 


// 全 局 变量 dvmAsmAltInstructionstart 
-global dvmAsmAltInstructionSstart 
.type dvmAsmAltInstructionstart, gSfunction 
// 代 码 段 
-text 
//ALThandler 数组 也 是 跟 字 节 码 指令 一 一 对 应 
dvmAsmAltInstructionstart = .L ALT OP NOP 
// 也 是 64 字 节 对 齐 
-balign 64 
-L ALT OP NOP: /* 0x00 */ 
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-balign 64 
-L ALT OP MOVE: /* 0X01 */ 


.balign 64 
// 详 细 分 析 一 个 ALT handler 的 结构 ， 其 余 ALThandler 类 似 
.L ALT OP IF GEZ: /* 0x3b */ 
// 把 线程 结构 的 breakFlags 放 到 r3 
ldrb r3, [rSELF, #offThread breakFlags] 
adrl lr, dvmAsmInstructionstart + (59 * 64) 
lide IIBASE， [rSELF, #0offThread curHandlerTable] 
/* 检 查 breakFlags 是 否 为 0， 如 为 0 直接 跳 到 mainhandler，1T 为 mainhandler 数组 里 对 
应 地 址 */ 
cmp E37 #0 


bxeq lr @ nothing to do - jump to real handler 
EXPORT_PC () 
mov 50 FPC @ arg0 
mov rl rEE @ argl 
InOV r2, rSELF @ arg2 
//breakFlags 被 置 位 ， 需 要 进一步 到 dvmCheckBefore 检查 
b dvmCheckBefore @ (dPC,dFP,self) tail call 
.balign 64 
//althander 数组 长 度 


.size dvmAsmAltIinstructionSstart, .-dvmAsmAltInstructionSstart 
.global dvmAsmAltInstructionEnd 

//althander 数组 结束 
dvmAsmAltInstructionEnd: 


(3) Handler 的 启用 
在 一 个 Dalvik 创建 之 初 ， 在 线程 的 管理 结构 里 记录 下 该 handler 的 地 址 。 


static Thread* allocThread (int interpStackSize) 

{ 
//mainHandlerTable 偏 移 值 为 88， 即 为 : offThread mainHandlerTable 
thread->mainHandlerTable = dvmAsmInstructionstart; 
// altHandlerTable 即 为 dvmAsmAltInstructionstart; 
thread->altHandlerTable = dvmAsmAltInstructionstart; 
//interpBreak.ctl.curHandlerTable 偏 移 值 为 40， 即 为 offThread_ 
curHandlerTable 
thread->interpBreak.ctl.curHandlerTable = thread->mainHandlerTable; 


17.4.2 ”运行 时 模型 与 基本 操作 


(1) ASM 解释 器 定义 了 专门 的 寄存 器 来 对 应 Dalvik 虚拟 机 模型 。 
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//rPC 指向 dalvik 操作 码 的 地 址 


#define FPC r4 
//fFP 指向 dalvik 的 帧 ， 这 是 在 编译 时 确定 下 来 的 寄存 器 组 
#define rFP 二 


//IrSELEF 指向 当前 线程 的 struct Thread 结构 
#define rSELF r6 

//rINST 为 当前 指令 

#define rINST r7 

//rIBASE 指向 字 节 码 handler 大 数组 的 基地 址 
#define rIBASE r8 


(2) 基本 操作 如 下 : 


// 把 当前 操作 码 作为 基 址 ， 偏 移 量 为 _countX2， 开 始 的 无 符号 半 字 加 载 到 寄存 器 _reg 中 
#define FETCH( reg, _count) ldrh _reg, [rPC, #((_count)*2)] 
// 把 rPC 和 rEFP 从 当前 线程 的 struct Thread 结构 里 取出 来 

#define LOAD PC FP FROM SELF() ldmia rSELF, {rPC, rFP} 
// 把 以 _vreg 为 索引 的 寄存 器 加 载 在 _reg 中 ，_vreg 的 索引 值 以 rFP 为 基准 

#define GET VREG( reg, vreg) ldr -reg; [rPP; vreg; 1s1 #2] 
// 从 struct InterpSaveState 取出 字 节 码 指令 地 址 与 帧 地 址 放 入 rPC 和 rFP 
#define LOAD PC FP FROM SELF() ldmia rSELF, {rPC, rFP} 


// 跳 到 _reg 字 节 码 对 应 的 handler， 因 为 与 64 字 节 对 齐 ， 所 以 1s1#6 
#define GOTO_OPCODE (_reg) add pc, rIBASE, reg, 1sl #6 


17.4.3 ASM Interpreter 入 口 


dvmMterpStdRun 是 解释 器 入 口 ,不 同 的 解释 器 有 着 不 同 的 实现 , 对 于 ASM Interpreter， 
不 仅 要 满足 Cto ASM 调用 规范 ， 而 且 承 接 好 DVM 虚拟 机 Context， 其 实现 如 下 : 


//ASM 版 解释 器 入 口 
dvmMterpStdRun : 
#define MTERP_ENTRY1 \ 
.Save {r4-r10,fp,lr}; \ 
stmfd sp!, {r4=r10, fp,1r} 
#define MTERP ENTRY2 \ 
.pad #4; \ 
sub sp, sp, #4 


/* 引 用 上 文 定 义 宏 ， 保 存 r4-r10, fp, 1r 寄存 器 */ 
tnstart 

MTERP ENTRY1 

MTERP_ ENTRY2 


/* 保存 栈 指针 */ 
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str sp, [r0, #offThread bailPtr] 


/* r0 里 存放 当前 线程 的 struct Thread */ 
mov rSELF, r0 
/* 从 当前 线程 struct Thread 的 struct InterpSaveState 里 取出 字 节 码 地 址 放 入 fPC， 
帧 地 址 放 入 rFP */ 
LOAD PC FP FROM SELF () 
/* rIBASE 就 是 handler 数组 的 地 址 */ 
ldr rIBASE, [rSELF, #offThread curHandlerTable] @ set rIBASE 


#if defined (WITH JIT) 
/*jit 功能 enable 时 的 处 理 */ 
.LentryInstr: 
/* Entry is always a possible trace start */ 
/* 把 struct Thread 的 pJitProfTable; 放 入 r0，JitProfTable 是 用 来 统计 热点 的 阔 值 
到 #/ 
ldr r0, [rSELF, #0offThread pJitProfTable] 
// 取 出 当前 指令 
FETCH_INST () 
mov 开业 二- 境 从 @ prepare the value for the new state 
Str rl, [rSELF, #0offThread inJitCodeCache] @ back to the interp land 
/* 如 果 pJitProfTable 为 0 就 表示 没有 热点 检测 ， 自 然 就 没有 jit 这 回 事 了 */ 
cmp r0,#0 @ is profiling disabled? 
#if !defined (WITH SELF VERIFICATION) 
/* 入 口 也 是 种 跳 转 ， 去 检测 是 否 热 点 ， 是 否 需 要 jit*/ 
bne common updateProfile @ profiling is enabled 


#else 


#endif 

/* 这 是 jit eable 时 有 效 的 编译 ， 第 一 条 字 节 码 已 经 被 取出 到 rINST， 把 rINST 里 的 指令 编码 
取出 来 放 到 寄存 器 ip 里 */ 

内 

GET INST OPCODE (ip) 

/* 根 据 寄存 器 ip 的 值 ， 跳 转 到 第 一 条 字 节 码 对 应 的 handler， 至 此 ASM Interpreter 启动 了 ， 
以 后 每 条 字 节 码 都 会 取出 其 后 的 字 节 码 ， 并 跳 入 对 应 的 handler */ 

GOTO_OPCODE (ip) 


#else 


/* start executing the instruction at rPC */ 


FETCH_INST() @ load rINST from rPC 
GET_INST _ OPCODE (ip) @ extract opcode from rINST 
GOTO_OPCODE (ip) @ jump to next instruction 


#endif 
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17.5 ”Interpreter 的 切换 


本 节 分 析 Dalvik 虚拟 机 是 通过 何 种 方式 选择 解释 器 的 。 
(1) 查找 系统 属性 里 解释 器 执行 模式 。 


int AndroidRuntime::startVm(JavaVM** pJavaVM, JNIEnv** PEnV) 
t 


// 取 出 系统 属性 dalvik.vm.execution-mode 
property get ("dalvik.vm.execution-mode", propBuf, ""); 
if (strcmp (propBuf, "int:portable") == 0) { 
/*portable 解释 器 ， 这 个 是 标 配 ， 但 是 不 是 默认 使 用 的 解释 器 。 在 有 些 新 的 架构 处 理 器 上 没 
有 别 的 解释 器 可 用 ， 可 以 先 用 这 个 */ 
executionMode = kEMIntPortable; 
} else if (strcmp(propBuf, "int:fast") == 0) { 
/* executionMode=2， 所 谓 fast 解释 器 就 是 汇编 优化 过 但 是 没有 JIT 功能 的 解释 器 ，JIT 对 
于 小 系统 有 可 能 带 来 副作用 ， 这 个 解释 器 是 不 错 选择 */ 
executionMode = kEMIntFast; 
#if defined (WITH JIT) 
} else if (strcmp (propBuf, "int:jit") == 0) { 
/*executionMode=3， 既 汇编 优化 又 带 JIT 功能 。 如 果 是 ARM v7 以 上 的 机 器 ， 就 是 这 个 了 */ 
executionMode = kEMJitCompiler; 
#endif 
} 


3 


(2) 解释 器 选择 。 
根据 执行 模式 选择 解释 器 。 在 解释 器 入 口 处 有 很 多 处 理 ， 这 里 仅 关注 解释 器 选择 。 


void dvmInterpret (Thread* self, const Method* method, JValue* PResult) 
{ 
if (gDvm.executionMode == kExecutionModeInterpFast) 
// dvmMterpStd 是 ASM 优化 但 不 带 JIT 功能 的 实现 
stdInterp = dvmMterpstd; 
#if defined (WITH JIT) 


else if (gDvm.executionMode == kExecutionModeJit) 
/*dvmMterpstd 是 ASM 优化 但 带 JIT 功能 的 实现 ， 与 上 者 的 区 别 在 编译 选项 WITH_JIT 是 
否 激活 */ 
stdInterp = dvmMterpstd; 
#endif 
Else 


//Portable 解释 器 ， 入 口 函数 是 void dvmInterpretPortable (…) 
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stdInterp = dvmInterpretPortable; 


17.6 ”Dalvik 运行 时 帧 结构 


在 Dalvik 运行 时 ， 每 个 函数 有 自己 的 Frame， 首 先 分 析 Dalvik 源码 里 对 Frame 结构 的 
描述 : 


Low addresses (0x00000000) 


i 4 < tack ptr (top of stack) 
VM-specific 入 
+ internal goop + 


生生 管 和 寿光 本 和 的 二 生 汪 + <-- curFrame: FP for cur function 
+ VO == local0 + 

十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

+ out0 + + vl == in0 + 

+ 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 十 -一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

+ outl + + v2 == inl 类 

二- 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 十 -一 -一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 


VM-specific 志 
internal goop + 


$s + <-- frame ptr (FP) for previous function 
+ V0 == local0 + 

Fe + 

+ V1 == locall + 

+ 一 -一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

+ v2 = in0 + 

+ 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

+ 53 == inl + 

ee + 

+ v4 == in2 + 

二 -一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 + 

A + <-- interpStackStart 


High addresses (0xffffffff) 


其 中 寄存 器 分 配 规则 是 由 Dalvik 编译 器 决定 的 ,而 VM-specific internal goop 就 是 struct 
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StackSaveArea， 该 结构 定义 如 下 : 


struct StackSaveArea { 


ud* prevFrame; 

// 该 PC 指针 位 并 不 是 二 进 制 的 r15， 而 是 当前 字 节 码 地 址 

const u2* savedPc; 

// 对 应 的 函数 结构 指针 

const Method* method; 

union { 
ud4 localRefCookie; 
/* 保 存 当前 字 节 码 的 地 址 到 其 成 员 变量 ， 通 常 在 EXPORT_PC () 时 发 生 */ 
const u2* currentPc; 


} xtra; 


}; 
字 节 码 的 地 址 保存 操作 如 下 : 


#define EXPORT PC() \ 

str rPC, [rFP, #(-sizeofStackSaveArea + offStackSaveArea currentPc)] 
其 中 offStackSaveArea_currentPc 被 定义 为 12，sizeofStackSaveRrea 即 为 struct 
StackSaveArea 结构 的 size。rFP 为 当前 帧 基地 址 ， 参 考 17.5 节 的 Frame 结构 ，[rFP， 
#(-sizeofStackSaveArea + offStackSaveArea currentPc)] 为 xtra. currentPc 所 


在 地 址 。 
17.7 JIT 


JIT 的 方式 可 以 函数 为 单位 也 可 以 trace 为 单位 。 前 者 整体 编译 一 个 函数 ， 后 者 编译 一 
个 热点 路 径 。Dalvik 目前 工作 方式 采用 第 二 种 ， 而 实际 上 Android 中 已 经 有 了 第 一 种 方式 
的 代码 , 但 是 在 Android 2.3 版 本 中 并 未 激活 。 本章 以 ASM Interpreter 为 基础 分 析 JIT 机 制 。 


17.7.1 热点 检测 


ASM Interpreter 准备 好 如 下 数据 : 


// 当 前 线程 struct Thread 的 pJitProfTable 放 入 r0 
r0 <= pJitProfTable (verified non-NULL) 

// 当 前 字 节 人 码 地 址 放 入 rPC 

PC <= Dalvik PC 

// FrINST 为 下 一 条 字 节 码 指令 


TINST <= next instruction 
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其 中 JitProfTable 在 bool compilerThreadStartup(void) 里 被 创建 ， 里 面 每 一 项 对 应 hash 
到 此 字 节 码 的 hot 程度 ， 初 始 设置 为 sDvmJitthreshold (gDvmJitthreshold 针对 不 同 架 构 有 
着 不 同 的 默认 值 ， 对 于 v5te 默认 值 为 200， 对 于 v7 架构 默认 值 为 40)， 每 当代 码 执行 到 此 
一 次 减 一 ， 当 减 为 0 时 做 JIT。 

热点 检测 跟 asm interpreter 一 样 ， 实 现在 文件 都 在 dalvik/vm/mterp/out/InterpAsm- 
armv7-a-neon.S 中 。 


common updateProfile: 

// 根 据 rPc 值 算出 hash 值 ， 再 根据 hash 值 找 出 JitProfTable 对 应 项 

eor r3,rPC,rPC,1sr #12 @ cheap, but fast hash function 

1sl r3,r3,#(32 - JIT PROF SIZE LOG 2) @ shift out excess bits 
ldrb rl1, [r0,r3,1sr #(32 - JIT PROF SIZE LOG 2)] @ get counter 
// 把 rINST 字 节 码 的 编号 放 到 寄存 器 ip 

GET_INST OPCODE (ip) 

// 将 JitProfTable 对 应 项 减 1 

subs rE1, E15#1 @ decrement counter 

// 将 结果 存 回 JitProfTable 对 应 项 

strb r1, [r0,r3,1sr #(32 - JIT PROF SIZE LOG 2)] @ and store it 
// 如 果 没 到 做 jit 阔 值 ， 返 回 asm interpreter 

GOTO_OPCODE IFNE (ip) @ if not threshold, fallthrough otherwise 
// 到 了 这 里 说 明 rPC 指向 的 解码 执行 足够 频繁 ， 需 要 做 jit 了 

/* Looks good, reset the counter */ 

// 取 出 阀 值 ， 并 存 入 JitProfTable 对 应 项 

ldr rl, [rSELF, #offThread jitThreshold] 

strb rl, [r0,r3,1sr #(32 - JIT PROF SIZE LOG 2)] @ reset counter 
// SAVEAREA FROM FP(fp)->xtra.currentPc = pc 


EXPORT_PC () 
mov r0,rPc 
mov rl1,rSELF 
// 去 jit 过 的 代码 段 里 查找 当前 rPC 地 址 的 字 节 码 段 是 否 存在 
bl dvmJitGetTraceAddrThread @ (pc, self) 
// 如 果 当前 *Pc 地 址 处 被 jit 过 ，r0 里 是 返回 地 址 ， 存 入 inJitCodeCache 
str r0, [rSELF, #0offThread inJitCodeCache] @ set the inJitCodeCache flag 
mov Ep @ argl of translation may need this 
mov lr, #0 @ in case target is HANDLER INTERPRET 
// 检 查 是 否 有 jit 过 的 二 进 制 代码 
cmp r0,#0 


#if !defined (WITH SELF VERIFICATION) 
// 直 接 跳 到 jit 过 的 二 进 制 代码 


bxne r0 @ jump to the translation 
//rPC 处 代码 还 没 做 过 jit 
mov r2,#kJitTSelectRequest @ ask for trace selection 


@ fall-through to common selectTrace 


#else 
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// 实 际 设备 上 这 个 编译 选项 是 disable， 不 考虑 这 种 WITH_SELF_VERIFICATION 情况 
#endif 
common selectTrace: 

/*struct Thread 的 interpBreak .ctl.subMode 记录 着 当前 jit 的 模式 */ 

lqdrh r0, [rSELF,#offThread subMode] 

/* 测 试 标志 位 ksubModeJitTraceBuild 和 ksubModeJitsV 若 不 为 零 , 说 明 当前 已 经 激活 
jit。 值 得 说 明 的 是 jit 工作 的 本 身 是 在 另外 一 个 线程 里 进行 .激活 jit 意味 着 当前 dalvik 
线程 向 jit 工作 线程 提交 了 jit 工作 申请 */ 

ands r0, #(kSubModeJitTraceBuild | kSubModeJitSV) 

// 如 果 已 经 激活 jit， 继 续 执行 当前 Dalvik 线程 即 可 

bne 3FE @ already doing JIT work, continue 

//r2 里 已 经 放 入 kJitTSelectRequest 

SEE r2, [rSELF, #0offThread jitstate] 
mov r0, rSELF 
EXPORT_PC () 

SAVE PC FP TO SELF() @ copy of pc/fp to Thread 

/* 进 入 jit 激活 操作 ，r0 里 是 当前 线程 的 struct Thread， 作 为 void 
dvmJitCheckTraceRequest (Thread* self) 的 参数 ， 该 函数 将 导致 
curHandlerTable 切换 成 ALThandlerTable*/ 


bl dvmJitCheckTraceRequest 
: 
FETCH_INST() 
// 重 新 取出 handlertable 基地 址 ， 这 时 已 经 发 生 了 改变 ， 切 换 成 ALThandlerTable 
ldr IIBASE， [rSELF, #offThread curHandlerTable] 
4: 
// 继 续 Dalvik 当前 线程 
GET_INST_OPCODE (ip) @ extract opcode from IINST 


GOTO_OPCODE (ip) 
/* no return */ 


#endif 


17.7.2 Mode 切换 


在 进入 该 函数 之 前 ，struct Thread 的 jitState 被 置 位 为 kJitTSelectRequest， 代 码 如 下 : 


void dvmJitCheckTraceRequest (Thread* self) 


人 
Switch (self->jitstate) { 
/*jitState 为 kJitTSelectRequest 时 该 分 支 有 效 ， 该 状态 在 common_ 
selectTrace: 处 被 设置 */ 


case kJitTSelectRequest: 
/*jitstate 状态 转换 成 kJitTSelect，dvmcheckjit 里 将 处 理 这 个 状态 */ 
Self->]jitState = kJitTSelect; 

/* kSubModeJitTraceBuild 为 0x4000， 这 里 将 导致 handlertable 的 切换 */ 


dvmEnableSubMode (self, kSubModeJitTraceBuild); 
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调用 层次 如 下 : 
void dvmEnableSubMode (Thread* thread, ExecutionSubModes subMode) 
{  // 参 数 supMode 为 kSupModeJitTraceBuild =0x4000 


updateInterpBreak (thread, subMode, true); 


} 
// 参 数 subMode 为 ksubModeJitTraceBuild =0x4000，enable 有 效 
void updateInterpBreak (Thread* thread， ExecutionSubModes subMode, bool 


enable) 
{ 
dof{ 


if (enable) 
newValue.ctl.subMode |= subMode; 
else 
newValue.ctl.subMode &= ~subMode; 
/* newValue.ct1.subMode 已 经 被 置 位 为 kxSubModeJitTraceBuild， 而 SINGLESTEP_ 


BREAK_MASK 有 效 位 包括 kSubModeJitTraceBuild/ 
if (newValue.ct1.subMode & SINGLESTEP BREAK MASK) 
newValue.ctl.breakFlags |= kInterpSingleStep; 


/* 因 为 newValue.ctl.breakFlags 被 置 位 为 kInterpSingleStep ， 这 里 导致 asm 
interpreter handlertable 切换 到 althandlertable*/ 
newValue.ctl.curHandlerTable = (newValue.ctl.breakFlags) ? 
thread->altHandlerTable : thread->mainHandlerTable; 
} while ( 
/*64 位 操作 ， 将 修改 后 的 值 更 新 给 union InterpBreak*/ 


dvmQuasiAtomicCas64(oldValue.all, newValue.all, 
&thread-> interpBreak. all) != 0); } 


17.7.3 JIT 提交 


JIT 时 需要 使 用 ALThandler， 其 结构 前 面 已 做 过 分 析 ， 这 里 有 两 点 需要 明确 。 

(1) 具体 工作 还 是 由 mainhandlertable 处 理 。 

(2) 每 次 将 处 理 递交 给 mainhandlertable 之 前 都 要 调用 void dvmCheckBefore(…), 检测 
当前 状态 并 提交 JIT 申请 。 

void dvmCheckBefore (Const u2 *pc, u4 *fp, Thread* self) 


{ee 
#if defined (WITH JIT) 
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// self->interpBreak.ctl.subMode 被 置 位 kSubModeJitTraceBuild 
if (self->interpBreak.ctl.subMode & 
(kSubModeJitTraceBuild | kSubModeJitSV) ) { 
if (self->interpBreak.ctl.subMode & kSubModeJitTraceBuild) { 
/*vid dvmCheckJit (…) 实现 具体 的 jit 递交 工作 */ 
dvmCheckJit (pc, self); 


#endif 


17.8 Compile 


Compile 是 指 JIT 的 编译 阶段 ， 这 里 完成 Dalvik 指令 到 机 器 指令 的 编译 动作 。 这 个 工 
作 分 为 两 部 分 ,首先 解释 器 完成 tracerun 的 分 析 之 后 , 然后 Dalvik 编译 线程 完成 编译 工作 。 


17.8.1 基础 数据 结构 


Compile 其 实 就 是 一 个 编译 器 的 后 端 ， 出 现 很 多 不 同 于 虚拟 机 的 基础 设施 ， 所 以 在 进 
入 到 Compile 之 前 ， 首 先 分 析 JIT Compile 使 用 到 的 基本 数据 结构 及 其 概念 。 

(1) struct DecodedInstruction 用 来 表示 一 条 Dalvik 指令 。 

Dalvik 操作 人 码 被 分 成 36 种 模式 ， 如 op、op vA, vB、op vA, #+B、op vAA, vBB, vCC 
等 。 该 结构 分 解 出 该 操作 码 的 操作 数 和 操作 码 。 


struct DecodedInstruction { 


ud va; //vA、vB、vC 都 是 分 解 出 来 的 操作 数 

ud vB; 

u8 vB_wide; /* for kFEmt511 */ 

ud4 vC; 

ud arg[5]; /* VvC/D/E/F/G in invoke or filled-new-array */ 


Opcode opcode; // 操 作 码 
InstructionIndexType indexType; 
}; 


(2) struct JitTraceRun 用 来 记录 一 个 tracerun 对 应 的 字 节 码 起 始 地 址 、 该 tracerun 包含 
的 字 节 码 长 度 等 信息 ， 或 者 用 来 记录 元 数据 信息 。 


struct JitTraceRun 1{ 
union { 
JitCodeDesc frag; //trace run 描述 
Void* meta; // 若 用 来 描述 元 数据 ， 该 指针 指向 元 数据 地 址 


} infos 
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u4 isCode:17// 通 过 这 一 位 来 辨别 是 否 是 元 数据 
u4 unused:31; 


}; 
(3) typedef struct MIR 表示 一 条 Dalvik 指令 编译 结构 。 


typedef struct MIR { 
// 上 述 字 节 码 描述 结构 
DecodedInstruction dalvikInsn; 
//Dalvik 指令 长 度 
unsigned int width; 
unsigned int offset; 
/* 一 个 tracerun 的 Dalvik 指令 通过 如 下 两 个 成 员 变 量 prev 和 next 挂 在 对 应 的 struct 
BasicBlock 结构 上 */ 
struct MIR *prev; 
struct MIR *next; 


//SSA 
struct SSARepresentation *ssaRep; 


} MIR; 


(4) struct BasicBlock 表示 一 个 TraceRun， 除 了 从 字 节 码 段 分 析出 的 TraceRun、entry 
等 ， 一 些 编译 器 加 入 的 代码 也 用 这 个 结构 来 表示 。 


typedef struct BasicBlock { 


// 本 基本 块 起 始 地 址 


unsigned int startOffset; 


/* 用 来 串 自己 的 typedef struct MIR 链表 */ 
MIR *firstMIRInsn; 

MIR *lastMIRInsn; 

// 紧 邻 的 基本 块 

struct BasicBlock *fallThrough; 

// 跳 转 或 调用 的 基本 块 


struct BasicBlock *taken; 


// 执 行 到 本 基本 块 前 面 的 基本 块 


BitVector *predecessors; 


struct { 
BlockListType blockListType; 
GrowableList blocks; // 盛 放 本 基本 块 的 容器 


} successorBlockList; 
} BasicBlock; 
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17.8.2 dalvik 指令 格式 分 析 


本 节 分 析 Dalvik 代码 格式 分 解 的 基本 例 程 。 
(1) 取 操作 码 。 


Opcode dexOopcodeFromCcodeUnit (u2 codeUnit) { 
// 取 出 低 8 位 
int lowByte = codeUnit & Oxff; 
if (lowByte != 0xff) { 
/* 如 果 低 8 位 不 全 为 1， 低 8 位 就 是 操作 码 */ 
return (Opcode) lowByte; 
} else { 
/* 耕 则 高 8 位 有 效 ，opcode 为 高 8 位 +0x100*/ 
return (Opcode) ((codeUnit >> 8) | 0x100); 


} 


(2) 指令 宽度 、 类 型 属性 。 
等 到 了 指令 操作 码 以 后 ， 指 令 宽度 、 格 式 、 属 性 等 信息 直接 查 表 即 可 。Dalvik 准备 了 
4 张 表 。 
InstructionInfoTables gDexOpcodeInfo = { 
gInstructionFormatTable, 
gInstructionIndexTypeTable, 
gOpcodeFlagsTable, 
gInstructionWidthTable 
}; 


如 果 要 知道 指令 宽度 ， 查 表 gInstructionWidthTable。 


size t dexGetWidthFromOpcode (Opcode opcode) 
{ 

return gDexOpcodeInfo.widths[opcode]; 
} 


要 知道 指令 格式 ， 查 表 gInstructionFormatTable。 
InstructionFormat dexGetFormatFromOpcode (Opcode opcode) 


return (InstructionFormat) gDexOpcodeInfo.formats[opcode]; 


17.8.3 TraceRun 分 析 


进入 到 TraceRun 的 背景 时 , ASM 解释 器 侦 测 到 JIT 的 发 生 , 切换 到 ALThandlerTable， 
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且 切 换 到 ALThandlerTable 以 后 TraceRun 的 分 析 就 开始 了 。 


void dvmCheckJit (const u2* pc, Thread* self) 
. i 
// lastPC 是 上 一 条 字 节 码 的 地 址 ， 第 一 条 字 节 码 进来 的 时 候 lastPCc 为 NULL 
Const u2 *lastPC = self->lastPC; 
// 当 前 字 节 码 地 址 
self->lastPC = pc; 


Switch (self->jitSstate) { 
int offset; 
DecodedInstruction decInsn; 
case kJitTSelect: 
// 在 开始 做 Tracerun 时 jitstate 为 kJitTSelect 
if (lastPC == NULL) break; 
/*Grow the trace around the last PC if jitState is kJitTSelect */ 


dexDecodeInstruction(lastPC, &decInsn); 


/* 如 果 遇 到 OP_PACKED_SWITCH 和 OP_SPARSE_SWITCH 指 令 说 明 TraceRun 分 析 
结束 */ 

if (self->totalTraceLen != 0 && 

OP_PACKED SWITCH 11 

decInsn.opcode == OP SPARSE SWITCH) ) { 

self->jitState = kJitTSelectEnd; 

break; 


(decInsn.opcode 


} 

//flags 是 前 一 条 指令 的 属性 

flags = dexGetFlagsFromOpcode (decInsn.opcode); 
//len 是 前 一 条 指令 的 宽度 

len = dexGetWidthFromInstruction (lastPC); 

// offset 是 前 一 条 指令 的 偏 移 函数 起 始 位 置 的 长 度 


offset = lastPC - self->traceMethod->insns; 


/* 根 据 指令 流 的 连续 性 来 判定 是 否 为 一 个 新 TraceRan 的 开始 */ 
if (lastPC != self->currRunHead + self->currRunLen) { 
/* 出 现 不 连续 的 指令 流 ， 新 TraceRun 开始 */ 
int currTraceRun; 
/* self->currTraceRun 标记 当前 tracerun 号 */ 
/* We need to start a new trace run */ 


currTraceRun = ++self->currTraceRun; 

/* 新 的 tracerun 开始 了 , currRunLen 置 位 为 0, currRunHead 为 起 始 字 节 
码 地 址 */ 

self->currRunLen = 0; 

self->currRunHead = (u2*) lastPC; 

/* 记 下 该 tracerun 的 相关 信息 */ 
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self->trace [currTraceRun] .info.frag.startOffset = offset; 
self->trace[currTraceRun] .isCode = true; 


} 
/* 当 前 tracerun， 指 令 个 数 增加 */ 
self->trace[self->currTraceRun] .info.frag-numInsts++7 
/* 本 次 跟踪 所 有 tracerun 的 指令 个 数 增加 */ 
self->totalTraceLent++; 
/* 当 前 tracerun 的 最 新 地 址 */ 
self->currRunLen += len; 
/* 
* If the last instruction is an invoke, we will try to sneak in 
* the move-result* (if existent) into a separate trace run 
*/ 
/* 代 人 码 注释 很 清楚 : 如 果 lastPC 指令 是 函数 调用 类 指令 , 则 tracerun 的 个 数 要 减 
一 ， 以 便 能 够 塞 进 一 个 move-result*/ 
{ 
// 指 令 gopcodeFlagsTable 表 里 指出 是 函数 调用 类 指令 
int needReservedRun = (flags & kInstrInvoke) ? 1 : 0; 
/* 一 次 tracerun 的 个 数 被 定 为 64， 如 果 超 过 了 64 即使 还 有 tracerun 也 不 在 
这 次 做 了 */ 
if (self->currTraceRun == 
(MAX_JIT RUN LEN - 1 - needReservedRun)) { 
X17 收工 
self->jitState = kJitTSelectEnd; 


} 
/* 如 果 不 是 无 条 件 跳 转 指令 ， 并 且 指 令 属性 里 有 kInstrCanBranch、 


kInstrCanSwitch、kInstrCanReturn、kInstrInvoke 属性 ， 说 明 本 次 
tacerun 的 跟踪 应 该 结束 了 */ 
if (!dexIsGoto(flags) && 
((flags & (kInstrCanBranch | 
kInstrCanSwitch | 
kInstrCanReturn | 
kInstrInvoke)) != 0)) { 
self->jitSstate = kJitTSelectEnd; 

// 对 于 函数 调用 的 处 理 

if (flags & kInstrInvoke) { 

// 用 3 个 struct JitTraceRun 放 函 数 调用 的 元 数据 信息 
insertClassMethodInfo(self, thisClass, curMethod, 
&decInsn); 

// 加 一 个 tracerun， 用 来 结束 返回 
insertMoveResult (lastPC, len, offset, self); 
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} 
// 如 果 遇 到 了 THROW， 收 工 
if ((decInsn.opcode == OP THROW) || (lastPC == pc))t{ 
self->]jitState = kJitTSelectEnd; 
} 
// 无 论 是 什么 情况 ， 如 果 超 过 了 64 个 tracerun， 收 工 
if (self->totalTraceLen >= JIT MAX TRACE LEN) { 
self->jitState = kJitTSelectEnd; 


case kJitTSelectEnd: 
//tracerun 的 分 析 收 工 了 ， 下 一 步 就 是 向 compiler 线程 提交 编译 申请 


{ 


// 把 前 面 收集 到 的 tracerun 信息 打包 在 JitTraceDescription 里 
JitTraceDescription* desc = 
(JitTraceDescription*)malloc (sizeof (JitTraceDescription)+ 


sizeof (JitTraceRun) * (self->currTraceRun+1)); 


// 向 compiler 线程 提交 编译 申请 
if (dvmCompilerWorkEnqueue ( 
self->currTraceHead, kWorkOrderTrace,desc)) { 
/* 入 队 */ 
if (gDvmJit.blockingMode) { 
dvmCompilerDrainQueue () ; 
} 


} else { 


} 
/* 尽 管 compile 的 工作 还 没 确定 完成 ， 但 是 对 于 ASM 解释 器 ，jit 
的 工作 到 此 已 经 完成 了 */ 
self->jitSstate = kJitDone; 
allDone = true; 

} 

break; 

case kJitDone: 
// allDone 恢复 为 true 
allDone = true; 


break; 


if (allDone) { 
// 这 里 导致 ASM 解释 器 切换 到 mainhandlertable 
dvmDisableSubMode (self, kSubModeJitTraceBuild); 
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} 
/* 从 这 里 返回 mianhandlertable， 再 也 没有 tracerun 的 检查 ，ASM 解释 器 恢复 正常 状态 */ 


return; 


17.8.4 MIR 


MIR 即 为 middle-level intermediate representation， 在 完成 对 trace 之 后 ， 要 对 收集 到 的 
traceruns 做 逻辑 分 析 ， 分 割 出 基本 块 ， 其 中 Dalvik 指令 以 MIR 形式 链接 起 来 。 


bool dvmCompileTrace (JitTraceDescription *desc, int numMaxInsts, 
JitTranslationInfo *info, jmp buf *bailPtr, 
int optHints) 

{ 

/* 参 数 JitTraceDescription *desc 里 面 是 收集 到 的 traceruns 信息 */ 

/* dexCode 是 这 些 traceruns 所 在 的 文件 */ 

const DexCode *dexCode = dvmGetMethodCode (desc->method); 

/* 首 先 定位 到 第 一 个 tracerun*/ 

const JitTraceRun* currRun = &desc->trace[0]; 

/* 第 一 个 tracerun 偏 移 地 址 */ 

unsigned int curOffset = currRun->info.frag.startOffset; 

unsigned int startOffset = curOffset; 

/* 第 一 个 tracerun 含有 的 字 节 码 数目 */ 

unsigned int numInsts = currRun->info.frag.numInsts; 

/* codePtr 直接 指向 第 一 个 tracerun 在 map 出 的 odex 文件 地 址 */ 

const u2 *codePtr = dexCode->insns + curOffset; 


/* 本 次 编译 结构 描述 */ 
CompilationUnit cUnit; 
GrowableList *blockList; 

/* 把 编译 信息 收集 到 cUnit 里 */ 
cUnit.method = desc->method; 
cUnit.traceDesc = desc; 
cUnit.jitMode = kJitTrace; 


/* 每 次 trace 都 包含 若干 struct BasicBlock， 本 次 trace 所 有 的 struct BasicBlock 都 
放 在 cUnit .blockList 里 记录 */ 

blockList = &g&cUnit.blockList; 

dvmInitGrowableList (blockList, 8); 

/* entry block 这 是 编译 器 自行 加 入 的 特殊 struct BasicBlock*/ 

CurBB = dvmCompilerNewBB (kEntryBlock, numBlocks++); 
dvmInsertGrowableList (blockList, (intptr 七 ) curBB); 
CurBB->startOffset = curOffset; 

/* DalvikByteCode 这 是 与 tracerun 对 应 的 struct BasicBlock， 每 个 tracerun 都 
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有 自己 的 struct BasicBlock， 当 前 这 个 entryCodeBB 对 应 第 一 个 tracerun */ 
entryCodeBB = dvmCompilerNewBB (kDalvikByteCode, numBlocks++); 
dvmInsertGrowableList (blockList, (intptr t) entryCodeBB); 
entryCodeBB->startOffset = curOffset; 
/* fallThrough 表示 struct BasicBlock 间 的 逻辑 关系 为 顺序 执行 ，entry block 后 
的 第 一 个 顺序 执行 struct BasicBlock 为 第 一 个 tracerun*/ 
curBB->fallThrough = entryCodeBB; 
/* entry block 不 需要 生成 MIR，curBB 从 第 一 个 tracerun 开始 */ 
CurBB = entryCodeBB; 
while (1) { 
/* 每 个 字 节 人 码 都 对 应 一 个 MIR */ 
MIR *insn; 
/* 字 节 人 码 的 宽度 */ 
int width; 
/* 为 当前 字 节 码 分 配 MIR */ 
insn = (MIR *)dvmCompilerNew (sizeof (MIR), true); 
/*offset 指向 当前 字 节 码 地 址 */ 
insn->offset = curOffset; 
/* 把 当前 字 节 码 宽度 分 析出 来 */ 


width = parseInsn(codePtr, &insn->dalvikInsn, cUnit.printMe); 


insn->width = width; 

traceSize += width; 

/* 把 当前 MIR 挂 到 当前 struct BasicBlock 的 链表 中 ， 根 据 字 节 码 的 先后 有 严格 的 顺 
序 关 系 */ 

dvmCompilerAppendMIR (curBB, insn); 

cUnit.numInstst+; 

/* 查 表 取 出 当前 字 节 人 码 的 属性 */ 

int flags = dexGetFlagsFromOpcode (insn->dalvikInsn.opcode); 


/*invoke 类 指令 的 处 理 */ 
if (flags & kInstrInvoke) { 

/* 对 于 invoke 类 指令 ， 在 当前 描述 编译 信息 的 struct JitTraceRun 结构 后 面 ， 连 续 放 
着 描述 类 信息 、 类 加 载 、 当 前 函数 的 元 数据 信息 ， 也 是 用 struct JitTraceRun 结构 来 
表示 。 这 些 信息 在 trace 分 析 时 就 被 收集 好 ， 参 见 void dvmCheckJit (…)*/ 

/* 当 前 函数 信息 */ 
const Method *calleeMethod = (const Method *) 
currRun[JIT TRACE CUR METHOD] .info.meta; 


CallsiteInfo *callsiteInfo = 
(CallsiteInfo *)dvmCompilerNew (sizeof (CallsiteInfo), true); 
/* 当 前 类 描述 信息 */ 
callsiteInfo->classDescriptor = (const char *) 
currRun[JIT TRACE CLASS DESC]. info.meta; 
/* 当 前 类 加 载 器 */ 
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callsiteInfo->classLoader = (Object *) 
CurrRun[JIT TRACE CLASS LOADER]. info.meta; 
callsiteInfo->method = calleeMethod; 


insn->meta.callsiteInfo = callsiteInfo; 


上 


/* 完 成 了 一 个 字 节 码 的 处 理 ，numInsts 递减 */ 

if (--numInsts == 0) { 

/* 当 前 tracerun 的 字 节 码 处 理 完毕 ， 遇 到 两 种 情况 */ 
if (currRun->info.frag.runEnd) { 
/* 所 有 的 tracerun 处 理 完毕 */ 

break; 
} else { 
/* 还 有 tracerun 待 处 理 */ 
dof{ 
/* currRun 指向 下 一 个 tracerun*/ 
CurrRun+t+; 
} while (!currRun->isCode); 


/* 为 新 的 tracerun 分 配 一 个 DalvikByteCode 类 型 的 struct BasicBlock, 用 

来 记录 这 个 tracerun 的 MIR*/ 
CurBB = dvmCompilerNewBB (kDalvikByteCode, numBlocks++); 
dvmInsertGrowableList (blockList, (intptr t) curBB); 
/* 为 新 的 tracerun 更 新 起 始 地 址 、 字 节 码 数 日 、odex 文件 地 址 等 信息 */ 
curOffset = currRun->info.frag.startOffset; 
numInsts = currRun->info.frag.numInsts; 
CurBB->startOffset = curOffset; 
codePtr = dexCode->insns + curOffset; 

} 

} else { 


/* 这 是 一 个 tracerun 内 的 处 理 ， 字 节 码 指针 更 新 */ 
curOffset += width; 
codePtr += width; 


17.8.5 ”基本 块 的 逻辑 关系 


在 完成 基本 块 MIR 链表 生成 之 后 , 要 分 析出 基本 块 之 间 的 关系 , 这 部 分 工作 仍 在 bool 
dvmCompileTrace(…) 中 进行 ， 代 码 如 下 : 


bool dvmCompileTrace (JitTraceDescription *desc, int numMaxInsts, 
JitTranslationInfo *info, jmp buf *bailPtr， 
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int optHints) 
{ 
/* 这 里 依次 取出 基本 块 ,然后 根据 每 个 基本 块 最 后 一 个 字 节 码 指出 的 地 址 和 其 他 基本 块 的 起 始 地 
址 对 比 来 判决 基本 块 之 间 的 关系 */ 
size t blockId; 
for (blockId = 0; blockId < blockList->numUsed; blockId++) { 
/* 根 据 基本 块 的 索引 依次 取出 基本 块 */ 
curBB = (BasicBlock *) dvmGrowableListGetElement (blockList, 
blockId); 
/* 取 出 基本 块 最 后 一 个 字 节 码 ， 前 面 介绍 过 ， 基 本 块 的 MIR 链表 是 有 着 严格 的 顺序 关系 ， 
lastMIRInsn 即 为 最 后 一 个 字 节 码 的 MIR*/ 
MIR *lastInsn = curBB->lastMIRInsn; 


/* curOffset 是 最 后 一 个 字 节 码 的 地 址 */ 

curOffset = lastInsn->offset7 

unsigned int targetOffset = curOffset; 

/* 最 后 一 个 字 节 人 码 的 地 址 + 最 后 一 个 字 节 码 的 宽度 ， 很 显然 这 是 在 没有 跳 转 的 情况 下 下 一 个 
基本 块 的 地 址 ， 把 这 种 情况 叫做 fall1Through*/ 

unsigned int fallThroughOffset = curOffset + lastInsn->width; 

bool isInvoke = false; 

const Method *callee = NULL; 

/*bool findBlockBoundary(…) 函数 的 工作 是 分 析 最 后 一 个 字 节 码 ， 如 果 是 INVOKE 
类 指令 ， 就 把 callee 函数 地 址 放 在 targetOffset， 如 果 是 GOTO，IF_ XX 类 指令 
就 把 目标 地 址 放 在 targetOffset */ 

findBlockBoundary (desc->method, curBB->lastMIRInsn, curOffset, 

&targetOffset, &isInvoke, &callee); 


/* Link the taken and fallthrough blocks */ 
BasicBlock *searchBB; 
/* 查 表 取 出 最 后 一 个 字 节 人 码 的 属性 */ 
int flags = dexGetFlagsFromOpcode (lastInsn->dalvikInsn.opcode); 
if (flags & kInstrInvoke) { 
cUnit.hasInvoke = true; 
} 
/* 如 果 不 是 函数 调用 ， 而 且 目 标 地 址 小 于 当前 地 址 ， 邦 么 循环 就 发 生 了 ，bool 
compileLoop (…) 专门 用 来 处 理 循环 */ 


if (isInvoke == false && 
(flags & kInstrCanBranch) != 0 && 
targetOoffset < curOffset && 
(optHints & JIT OPT NO LOOP) == 0) { 
/* 编 译 循环 体 */ 


return compileLoop(&cUnit, startOffset, desc, numMaxInsts, 
info, bailPtr, optHints); 
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/* 下 面 依次 扫描 所 有 的 基本 块 ， 检 查 它 们 的 起 始 地 址 是 否 是 当前 块 的 跳 转 目标 地 址 ， 或 者 
是 紧邻 当前 块 的 地 址 */ 

size t searchBlockId; 

for (searchBlockId = blockId+1; searchBlockId < blockList->numUsed; 


searchBlockId++) { 
searchBB = (BasicBlock *) dvmGrowableListGetElement (blockList, 


searchBlockId); 
/* 表 明 当 前 块 最 后 一 条 指令 的 跳 转 地 址 是 searchBB 的 起 始 地 址 */ 
if (targetOffset == searchBB->startOffset) { 
/* taken 描述 两 者 的 跳 转 /调用 关系 */ 
CurBB->taken = searchBB; 
/* 当 前 块 在 searchBB 基本 块 predecessors 位 图 置 位 */ 
dvmCompilerSetBit (searchBB->predecessors, curBB->id); 


} 
/* 表 明 当 前 块 最 后 一 条 指令 后 面 的 地 址 就 是 searchBB 的 起 始 地 址 */ 
if(fallThroughOffset == searchBB->startOffset) { 
/* taken 描述 两 者 的 顺序 执行 关系 */ 
curBB->fallThrough = searchBB; 
/* 当 前 块 在 searchBB 基本 块 predecessors 位 图 置 位 */ 
dvmCompilerSetBit (searchBB->predecessors, curBB->id); 


} 


17.8.6 ”寄存 器 分 配 


1.， 寄存器 分 配 的 步骤 


(1) 统计 当前 函数 使 用 的 Dalvik 虚拟 机 寄存 器 ， 参 见 “Dalvik 寄存 器 编译 模型 ”一 节 。 

(2) 分 析 每 一 条 MIR 的 操作 数 ， 为 其 分 配 寄存 器 (不 是 实际 的 ARM 寄存 器 ， 仅 为 抽 
象 的 寄存 器 )， 并 将 该 寄存 器 与 Dalvik 虚拟 机 寄存 器 建立 对 应 关系 。 

(3) 在 Dalvik jit 里 有 个 SSA 概念 ， 它 代表 一 个 抽象 的 寄存 器 组 。SSA 的 寄存 器 组 跟 
Dalvik 寄存 器 组 一 一 对 应 。 每 个 struct CompilationUnit 结构 包含 两 个 数组 int 
*dalvikToSSAMap; 和 和 GrowableList *ssaToDalvikMap:。 前 者 以 Dalvik 寄存 器 号 做 数组 索引 
可 以 找到 对 应 的 SSA 寄存 器 号 ， 后 者 以 SSA 寄存 器 号 做 数组 索引 可 以 找到 对 应 的 Dalvik 
寄存 器 号 。 

(4) 接 下 来 需要 分 析 每 条 Dalvik 指令 的 寄存 器 需求 , 其 做 法 是 扫描 每 一 个 BasicBlock， 
然后 针对 每 一 个 BasicBlock 的 每 一 条 MIR 做 寄存 器 使 用 情况 分 析 。 


bool dvmCompilerDoSSAConversion (CompilationUnit *cUnit, BasicBlock *bb) 


{ 
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MIR *mir; 


for (mir = bb->firstMIRInsn; mir; mir = mir->next) { 
/*struct SSARepresentation 记录 每 条 Dalvik 指令 的 抽象 寄存 器 需求 */ 


mir->ssaRep = (struct SSARepresentation *) 


dvmCompilerNew (sizeof (SSARepresentation), true); 


/* 取 出 该 Dalvik 操作 码 的 属性 ， 每 个 操作 码 属性 由 若干 代表 目标 操作 数 、 源 操作 数 等 属 


性 位 组 成 ， 根 据 属性 位 可 以 分 析出 需要 多 少 寄存 器 、 数 据 最 终 是 存 到 哪个 寄存 器 、 是 否 
需要 浮 点 寄存 器 */ 


int dfAttributes = 


dvmCompilerDataFlowAttributes [mir->dalvikInsn.opcode]; 


/* 源 操作 数 寄存 器 需求 计数 */ 


int numUses = 0; 


/* 宏 DF_HAS_USE 定义 如 下 


#define DF_HAS_USES 


(DF UA | DF UB | DF UC | DF UA WIDE | \ 
DF_UB WIDE | DF_UC WIDE) 


其 中 每 个 DF_UXX 代表 一 个 源 操作 数 寄存 器 的 需求 


wf 


if (dfAttributes & DF HAS USES) { 


} 


if (dfAttributes & DF UA) { 

/* 如 果 需 要 源 操作 数 寄存 器 ， 增 加 一 个 寄存 器 需求 */ 
numUses++7 

} else if (dfAttributes & DF UA WIDE) { 

/* 如 果 需 要 源 操 作 数 寄存 器 ， 但 类 型 为 WIDE， 增 加 两 个 寄存 器 需求 */ 
numUses += 2; 

’ 

/* 如 果 需 要 源 操作 数 可 能 有 多 个 ， 依 次 检查 */ 

if (dfAttributes & DF UB) { 
numUsest+t+; 

} else if (dfAttributes & DF UB WIDE) { 
numUses += 2; 


/* 给 统计 出 来 的 源 操作 数 寄存 器 分 配 指 针 数 组 和 浮 点 判定 数组 */ 


if (numUses) { 


mir->ssaRep->numUses = numUses; 

mir->ssaRep->uses = (int *)dvmCompilerNew (sizeof (int) * numUses, 
false); 

mir->ssaRep->fpUse = (bool *)dvmCompilerNew(sizeof (bool) * 

numUses, 


false); 


} 
/* 目 的 地 操作 数 寄 存 器 计数 器 */ 
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int numDefs = 0; 
/* 宏 DFE_HAS_DEFS 定义 如 下 


#define DF HAS DEFS (DF_DA | DF_DA WIDE) 
其 中 每 个 DF_DXX 代表 一 个 目的 地 操作 数 寄存 器 的 需求 
*/ 


if (dfAttributes & DF HAS DEFS) { 
/* 目 的 地 操作 数 寄存 器 只 可 能 有 一 个 ， 无 非 是 普通 类 型 还 是 WIDE 类 型 */ 
numDefs++7 
if (dfAttributes & DF DA _ WIDE) { 
numDefs++7 


/* 给 统计 出 来 的 目的 地 操作 数 寄存 器 分 配 指针 数组 和 浮 点 判定 数组 */ 
if (numDefs) { 
mir->ssaRep->numDefs = numDefs; 
mir->ssaRep->defs = (int *)dvmCompilerNew (sizeof (int) * numDefs, 
false); 
mir->ssaRep->fpDef = (bool *)dvmCompilerNew(sizeof (bool) * 
numDefs, 
false); 


DecodedInstruction *dInsn = &mir->dalvikInsn; 
/* 再 次 检查 源 操作 数 */ 
if (dfAttributes & DF_HRAS_USES) { 
numUses = 0; 
if (dfAttributes & DF UA) { 
/* 前 面 分 配 的 浮 点 判定 数组 的 用 处 在 这 里 体现 出 来 了 ， 如 果 指 令 的 源 操作 数 浮 点 属性 被 置 位 ， 显 然 
这 是 个 浮 点 操作 ，fpUse [] 对 应 为 位 被 置 位 */ 
mir->ssaRep->fpUse [numUses] = dfAttributes & DF FP A; 
/* 根 据 Dalvik 编码 里 使 用 的 寄存 器 号 ， 找 到 SSA 对 应 的 寄存 器 号 ， 并 在 uses [] 数组 里 记 住 这 
个 SSA 寄存 器 */ 
handleSSAUse (cUnit, mir->ssaRep->uses, dInsn->vA, 
numUses++); 
} else if (dfAttributes & DF UA WIDE) { 
/* 如 果 源 操作 是 WIDE, 那么 源 操作 数 A 需要 使 用 两 个 Dalvik 寄存 器 , 相应 的 也 需要 使 用 两 个 SSA 
寄存 器 ， 处 理 方法 和 前 者 相同 ， 只 是 这 里 需要 将 dInsn->vA 和 dInsn->vA+1 分 别处 理 一 次 */ 


mir->ssaRep->fpUse [numUses] = dfAttributes & DF FP A; 
handleSSRAUse (cUnit, mir->ssaRep->uses, dInsn->vA, 
numUses++) 7 

mir->ssaRep->fpUse[numUses] = dfAttributes & DF FP A; 
handleSSRAUse (cUnit, mir->ssaRep->uses, dInsn->vA+tl, 


numUsest++); 
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} 
/* 下 面 处 理 源 操作 数 B、C， 方 法 和 源 操作 数 相 同 */ 


if (dfAttributes & DF UB) { 


} else if (dfAttributes & DF UB WIDE) { 


} 
if (dfAttributes & DF UC) { 


} else if (dfAttributes & DF UC WIDE) { 


} 
} 
/* 处 理 目的 地 操作 数 */ 
if (dfAttributes & DF HAS DEFS) { 
/* 若 为 浮 点 数 寄存 器 ，fpUse [] 对 应 为 位 被 置 位 */ 
mir->ssaRep->fpDef[0] = dfAttributes & DF FP A; 
/* 在 defs [] 对 应 项 记 下 是 哪个 SSA 寄存 器 */ 
handleSSADef (cUnit, mir->ssaRep->defs, dInsn->vA, 0); 
if (dfAttributes & DF DA WIDE) { 
/* 目 的 地 操作 也 有 可 能 是 WIDE， 这 里 处 理 第 二 个 寄存 器 ， 第 一 个 寄存 器 前 面 已 经 默认 处 理 了 */ 
mir->ssaRep->fpDef[1] = dfAttributes & DF FP A; 
handleSSADef (cUnit, mir->ssaRep->defs, dInsn->vA+1l, 1); 


y 
2. ARM 寄存 器 的 使 用 


/* 可 用 的 整数 寄存 器 ， 里 面 少 了 r*5 r6， 因 为 r5 r6 分别 被 Dalvik 解释 器 当 rFP 和 SELFE， 

使 用 这 两 个 不 能 被 自由 分 配 。 而 r4 通常 会 被 EXPORT_PC () 保存 起 来 可 以 被 恢复 ， 所 以 r4 也 可 自 

由 分 配 ，r13 r14 r15 分 别 是 sp、1lr、pc， 所 以 这 些 寄存 器 也 不 能 自由 分 配 

a 

static inmt coreTemps{] = {0, r1, r2, r3, £4PC, r1, £80. £9, 10, ll, £12}s 

/* 可 用 的 浮 点 寄存 器 */ 

static int fpTemps{[l = {fr16; frl7l, fri6; frli9; fr20, fr21; fr22, fr23, 
fr24, fr25, fr26, fr27, fr28, fr29, fr30, fr31}; 


void dvmCompilerInitializeRegAlloc (CompilationUnit *cUnit) 
{ 


/* 寄 存 器 池 : ARM 寄存 器 的 整体 管理 结构 */ 


RegisterPool *pool = (RegisterPool *)dvmCompilerNew (sizeof (*pool), 
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七 rue) 
cUnit->regPool = pool; 
pool->numCoreTemps = numTemps; 
/* 每 个 寄存 器 对 应 一 个 struct RegisterInfo， 为 每 个 可 用 整数 寄存 器 分 配 struct 
RegisterInfo 结构 */ 
pool->coreTemps = (RegisterInfo *) 
dvmCompilerNew (numTemps * sizeof(*cUnit->regPool->coreTemps), 
true); 
pool->numFPTemps = numFPTemps; 
/* 每 个 可 用 浮 点 寄存 器 分 配 struct RegisterInfo 结构 */ 
pool->FPTemps = (RegisterInfo *) 
dvmCompilerNew (numFPTemps * sizeof (*cUnit->regPool->FPTemps), 


true); 


/* 为 每 个 可 用 寄存 器 初始 化 struct RegisterInfo 结构 ， 主 要 内 容 如 下 : 
编号 。 每 个 寄存 器 都 有 自己 的 编号 ， 该 编号 在 enum NativeRegisterPool 里 定义 ; 
是 否 被 使 用 。 该 寄存 器 是 否 被 分 配 出 去 了 ; 
是 否 配对 使 用 。 本 寄存 器 是 否 需要 跟 其 他 寄存 器 一 起 使 用 
机 
dvmCompilerInitPool (pool->coreTemps, coreTemps, pool->numCoreTemps); 
dvmCompilerInitPool (pool->FPTemps, fpTemps, pool->numFPTemps); 
pool->nullCheckedRegs = 
dvmCompilerAllocBitVector (cUnit->numSSARegs, false); 


extern RegLocation dvmCompilerEvalLoc (CompilationUnit *cUnit, RegLocation 


166; 
int regClass, bool update) 


/* 先 从 已 分 配 出 去 的 ARM 寄存 器 里 找 ， 是 否 有 对 应 当前 SSA 寄存 器 的 */ 
loc = dvmCompilerUpdateLoc(cUnit, loc); 


/* 在 尚未 分 配 出 去 的 可 自由 分 配 ARM 寄存 器 里 找 一 个 ARM 寄存 器 */ 
newReg = dvmCompilerAllocTypedTemp (cUnit, loc.fp, regClass); 


loc.lowReg = newReg; 


if (update) { 
loc.location = kLocPhysReg; 
/* 这 个 新 分 配 出 来 的 ARM 寄存 器 对 应 地 记录 下 SSA 寄存 器 号 */ 
dvmCompilerMarkLive (cUnit, loc.lowReg, loc.sRegLow); 


} 


return loc; 
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178:.7 .LIR 


LIR 与 机 器 架构 相关 ， 每 个 LIR 对 应 相应 机 器 指令 ， 有 自己 的 操作 码 和 操作 数 。 对 于 
每 一 个 MIR， 生 成 若干 LIR。LIR 的 生成 有 如 下 两 个 步骤 : 

(1) 查找 字 节 码 的 格式 ， 尽 管 Dalvik 字 节 码 有 200 多 个 ， 但 是 根据 其 操作 数 的 个 数 和 
格式 可 以 将 其 分 为 36 大 类 。 通 常 相同 功能 的 字 节 码 的 编码 格式 都 相同 ， 如 字 节 码 
OP IF EQZ、 OP IF NEZ、OP IF LTZ、OP IF _ GEZ、OP IF_ GTZ、OP IF _LEZ 都 属于 
Fmt21t 类 型 的 字 节 码 编码 格式 。 

(2) 根据 某 种 格式 的 字 节 码 ， 并 生成 相关 的 ArmLIR 并 分 配对 应 的 ARM 操作 码 类 型 ， 
对 于 v7 架构 使 用 的 thumb2 指令 集 。 值 得 注意 的 是 ， 并 不 是 一 条 MIR 对 应 一 条 工 及 ， 实 际 
上 根据 不 同 的 MIR 功能 ， 通 常会 有 多 条 LIR 来 实现 ， 代 码 如 下 : 

void dvmCompilerMIR2LIR (CompilationUnit *cUnit) 


fw 
/* 分 为 两 个 层次 ,首先 依次 取出 每 个 基本 块 ， 然 后 针对 每 个 基本 块 的 MIR 链表 生成 对 应 LIR， 对 于 
ARM 架构 LIR 的 实现 为 struct ArmLIR*/ 

for (BasicBlock *nextBB = bb; nextBB != NULL; nextBB = cUnit-> 


nextCodegenBlock) { 
bb = nextBB; 
/visited 标识 着 该 基本 块 将 产生 LIR/ 
bb->visited = true; 
cUnit->nextCodegenBlock = NULL; 
for (mir = bb->firstMIRInsn; mir; mir = mir->next) { 


/* 取 出 Dalvik 字 节 码 */ 

Opcode dalvikOpcode = mir->dalvikInsn.opcode; 

/* 分 析出 该 字 节 人 码 格式 */ 

InstructionFormat dalvikFormat = 
dexGetFormatFromOpcode (dalvikOpcode); 


/* 根 据 该 字 节 码 的 类 型 进行 不 同 的 处 理 */ 
switch (dalvikFormat) { 


case kFmt21h: 
notHandled = handleFmt21h(cUnit, mir); 


break; 


case kFmt21t: 
/*OP_IF_XXX 类 型 字 节 码 ， 以 此 例 详细 分 析 */ 
notHandled = handleFmt21t (cUnit, mir, bb, 
labelList); 


break; 
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default: 
notHandled = true; 


break; 


下 面 以 OP_IF_ XXX 字 节 码 为 例 ， 分 析 其 LIR 的 生成 ， 代 码 如 下 : 


static bool handleFmt21t (CompilationUnit *cUnit, MIR *mir, BasicBlock *bb, 


ArmLIR *labelList) 


ee 
Opcode dalvikOpcode = 
ArmConditionCode cond; 


/* 通过 检查 目标 地 址 与 当前 地 址 的 先后 来 判定 是 否 backward 跳 转 */ 
(bb->taken->startOffset <= mir->offset); 


bool backwardBranch = 


mir->dalvikInsn.opcode; 


RegLocation rlSrc = dvmCompilerGetSrc(cUnit, mir, 0); 


rlsrc = loadValue (cUnit, 


/* 生 成 比较 指令 的 ArmLIR， 使 用 的 ARM 操作 码 为 kThumbCmpRR*/ 


EISLE: 


kCoreReg); 


opRegImm(cUnit, kOpCmp, rlSrc.lowReg, 0); 


/* 跟 据 Dalvik 字 节 人 码 的 生成 条 件 码 */ 
switch (dalvikOpcode) { 


case OP IF EQ2: 
/* 条 件 码 位 等 于 */ 


cond = kArmCondEq; 
break; 

case OP IF NEZ: 
/* 条 件 码 位 等 于 */ 
cond = kArmCondNe; 
break; 

case OP _ IF LTZ: 
/* 条 件 码 位 小 于 */ 
cond = kArmCondLt; 
break; 

case OP IF GEZ: 
/* 条 件 码 位 大 于 */ 
cond = kArmCondGe; 


break; 
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default: 


} 

/* 生 成 kThumb2BCond 指令 的 ArmLIR， 该 指令 条 件 公 已 在 前 面 被 检 出 。 这 是 taken 分 支 ， 跳 转 

到 另 一 个 tracerun */ 

genConditionalBranch (cUnit, cond, &labelList[bb->taken->id]); 

/* This mostly likely will be optimized away in a later phase */ 

/* 生 成 kThumbBUncond 指令 的 RrmLIR， 这 是 fall1Through 分 支 ， 正 如 注释 里 指出 的 一 样 ， 这 

条 LIR 可 能 被 优化 掉 */ 

genUnconditionalBranch (cUnit, &labelList[bb->fallThrough->id]); 
return false; 


17.8.8 Codecache 


Codecache 即 为 存放 机 器 代码 段 的 cache， 其 中 包括 如 下 类 型 的 代码 。 
(1) 基本 例 程 。 这 些 代码 是 ji 的 辅助 例 程 ， 供 JIT 生成 代码 使 用 。 其 实现 在 : 


./dalvik/vm/compiler/template/out/CompilerTemplateAsm-armv7-a-neon.s 


(2) 编译 代码 。 根 据 Dalvik 字 节 码 生 成 的 机 器 代码 段 。 

(3) 中 间 代 码 。 用 来 进入 、 连 接 译 代码 的 代码 ， 通 常 根据 特殊 基本 块 生成 。 

每 一 个 基本 例 程 对 应 intptr_t templateEntryOffsets[] 数 组 的 其 中 一 项 ， 代 表 该 基础 例 程 
偏 移 基 本 例 程 的 起 始 地 址 dvmCompilerTemplateStart 的 长 度 。 


#define JIT TEMPLATE(X) templateEntryOffsets[i++] = \ 
/* 例 程 地 址 -起 始 地 址 */ 
(intptr 七 ) dvmCompiler TEMPLATE ##X - (intptr t) dvmCompiler 
Templatestart; 
/* 该 文件 定义 了 每 个 例 程 名 */ 
#include "../../../template/armv5te-vfp/TemplateOpList.h" 
#undef JIT_ TEMPLATE 


bool dvmCompilerSetupCodeCache (void) 
{ ee 
/* 创建 code cache 的 虚拟 内 存 */ 

fd = ashmem create region("dalvik-jit-code-cache", gDvmJit. 


codeCacheSize); 


gDvmJit.codeCache = mmap (NULL, gDvmJit.codeCacheSize, 
PROT READ | PROT WRITE | PROT EXEC, 
MAP PRIVATE , fd, 0); 


// 把 基础 例 程 拷贝 到 codecache 最 开始 处 


memcpy ( (void *) gDvmJit.codeCache, 
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(void *) dvmCompilerTemplatestart, 
templateSize); 


17.9 Dalvik ART 


截至 本 书 即 将 完成 之 时 ，Android 又 推出 了 ART。 笔 者 本 来 不 想 在 没有 读 过 相关 代码 
之 前 发 表 评 论 ， 但 是 ART 在 架构 之 中 的 位 置 如 此 重要 , 将 会 在 未 来 引起 Android 架构 惊 心 
动 魄 的 演进 ， 笔 者 禁不住 要 将 以 下 内 容 加 入 本 书 。 

首先 ， 解 释 器 不 是 虚拟 机 全 部 。 虚 拟 机 由 进 线程 管理 、 内 存 管理 、 基 础 类 库 等 组 成 。 
笔者 认为 解释 器 应 该 属于 虚拟 机 进 线程 管理 的 一 部 分 。ART 可 以 理解 为 一 种 特殊 的 解释 
器 ， 一 个 将 解释 器 指令 handler 替换 掉 对 应 字 节 码 的 二 进 制 镜 像 。 所 以 ART 并 不 是 替换 掉 
了 Dalvik 虚拟 机 而 是 为 Dalvik 提供 了 一 种 新 的 解释 器 ，Dalvik 的 进 线程 管理 、 内 存 管 理 、 
基础 类 库 还 在 ， 寄 存 器 编译 模型 还 在 。 

ART 带 来 的 负面 影响 是 其 代码 长 度 大 幅 增加 ， 即 使 能 够 进行 优化 ， 也 是 字 节 码 长 度 和 
字 节 码 handler 长 度 的 区 别 。 这 样 导 致 代码 密度 增 大 ， 存 储 空间 和 内 存 使 用 增 大 。 

不 过 存储 空间 、 内 存 空 间 是 很 容易 获取 的 ， 随 着 半导体 技术 的 发 展 ， 其 单位 成 本 都 在 
急剧 下 降 。 那么 可 以 期 待 : 改进 解释 器 使 其 能 够 像 执行 native 函数 一 样 执行 ART 化 的 类 成 
员 函 数 ， 把 基础 类 库 ART 化 ; 将 某 些 热点 函数 编译 并 保存 下 来 ; 支持 Java 语法 使 其 在 函 
数 定义 时 能 够 指出 其 属性 在 编译 时 直接 编译 为 二 进 制 。 

也 许 Java 的 捍卫 者 会 说 这 样 会 破坏 了 Java 的 精髓 ， 但 是 在 手机 和 嵌入 式 领域 ， 有 几 
个 Java 的 拥 在 。 
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18.1 Parcel 


Parcel 不 仅仅 是 一 包 数 据 的 体现 ，Parcel 是 布局 在 从 Java 层 到 内 核 层 系统 对 象 识 别传 
递 机 制 。 对 象 识别 最 关键 的 处 理 在 内 核 , 内 核 里 决定 Parcel 里 对 象 的 属性 ，C++ 层 将 Parcel 
里 的 对 象 实体 化 ，Java 层 将 Parcel 在 Java 层 实体 化 ， 但 是 尽管 在 每 一 层 都 有 实体 对 象 ， 这 
些 实体 对 象 只 是 在 各 层 体 现 不 同 ， 其 意义 都 是 相同 的 。 系 统 中 大 量 的 service 对 象 和 非 
service 对 象 的 本 地 远程 机 制 的 建立 都 是 依靠 Parcel 机 制 来 完成 。 本 章 着 重 分 析 service 对 象 
的 本 地 及 远程 生成 机 制 ， 而 在 一 些 实例 章节 分 析 非 service 对 象 的 本 地 及 远程 建立 机 制 。 

另外 , 尽管 内 核 层 是 对 象 识别 的 主体 , 为 了 章节 划分 方便 , 本 节 仅 分 析 Parcel 的 在 C++ 
和 Java 层 的 机 制 ， 内 核 层 机 制 参 见 Binder 驱动 一 节 。 


18.1.1 C++ 层 的 Parcel 


Parcel 的 处 理 分 为 压 包 和 解 包 过 程 ， 解 包 较为 复杂 ， 且 更 能 体现 parcel 的 意义 ， 为 节 
省 篇 幅 本 节 仅 分 析 解 包 。 


//Parce 解 包 
status t unflatten binder (Const sp<ProcessState>& proc, 
const Parcel& in, sp<IBinder>* out) 


{ 


if (flat) { 
Switch (flat->type) { 
case BINDER TYPE BINDER: 
// 本 地 对 象 ， 直接 取出 即 可 


*out = static cast<IBinder*> (flat->cookie); 


case BINDER TYPE HANDLE: 
// 代 理 对 象 的 处 理 见 下 文 
*out = Proc->getStrongProxyForHandle (flat->handle); 
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} 

// 代 理 对 象 的 处 理 

sp<IBinder> ProcessState: :getStrongPrOXYForHandle (int32 t handle) 

{ 

sp<IBinder> result; 
AutoMutex 1 (mLock); 

/* 每 个 进程 有 个 存储 机 构 ， 存 放 着 该 进程 使 用 的 Ibinder, 其 索引 通过 Ibinder 的 handle 来 实 
现 ， 这 里 是 在 存储 机 构 查 找 handle 为 零 的 IBinder， 如 果 不 存在 也 为 其 分 配 一 个 存储 项 
handle entry*/ 

handle entry* e = lookupHandleLocked (handle); 


if (e != NULL) { 
IBinder* b = e->binder; 


if (b == NULL || !e->refs->attemptIncWeak (this)) { 
/*0 号 handle 不 存在 ， 为 其 建立 class BpBinder 对 象 ， 并 初始 化 其 mHandle 成 
员 变 量 */ 


b = new BpBinder (handle); 
e->binder = b; 

if (b) e->refs = b->getWeakRefs () ; 
result = b; 


return result; 


18.1.2 ”Java 层 的 Parcel 


同 C++ 层 一 样 ，Java 层 也 是 分 析 其 解 包 过 程 。 不 同 于 C++ 层 ，Java 层 没 有 显示 的 解 包 
函数 ， 也 不 需要 这 样 做 。Java 层 的 解 包 体 现在 对 包 内 对 象 的 引用 上 。 


//Java 层 的 Parcel 
public final class Parcel { 


// 对 象 引 用 ， 通 过 该 函数 获得 Java 层 对 象 
public final IBinder readStrongBinqder () { 
return nativeReadStrongBinder (mNativePtr); 


} 


} 
在 JIN 层 nativeReadStrongBinder 函数 调用 如 下 函数 : 


static jobject android os Parcel readstrongBinder (JNIEnv* env, jclass 


clazz, jint nativePtr) 


{ 
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if (parcel != NULL) { 
/*C++ 层 的 readStrongBinder 其 实 就 是 unflatten binder， 本 地 对 象 获得 BBinder， 
代理 对 象 获 得 BpBinder*/ 
return javaObjectForIBinder (env, parcel->readstrongBinder () ) 7 
} 
return NULL; 


// 该 函数 的 作用 是 通过 其 获得 val 参数 ， 生 成 其 Java 层 的 代理 对 象 


jobject javaObjectForIBinder (UNIEnv* env, const sp<IBinder>& val) 
{ 


if (val->checkSubclass (ggBinderOffsets)) { 
/* 跑 到 这 里 说 明 遇 到 了 一 个 本 地 对 象 ， 但 本 地 对 象 不 在 这 里 生成 ， 且 已 经 存在 ， 这 里 直接 
找到 本 地 对 象 返回 即 可 */ 


jobject object = static_cast<JavaBBinder*> (val.get())->object(); 


} 


// 别 的 线程 抢先 一 步 
jobject object = (jobject)val->findObject (ggBinderProxyOffsets); 
if (object != NULL) { 
// 既 然 已 经 生成 weak 引用 之 
jobject res = env->CallObjectMethod(object, gWeakReference 
Offsets.mGet); 


} 
/* 真 正 的 对 象 生成 ， 进 入 Java 解释 器 生成 对 象 。 准 确 的 说 是 生成 一 个 对 象 ， 青 进入 解释 器 执 
行 其 构造 函数 */ 

object = env->NewObject (gBinderProxyOffsets.mClass, gBinderProxyOffsets. 
mConstructor); 

// 成 功 生 成 class BinderProxy 对 象 

if (object != NULL) { 

// 在 mobject 记 下 Java 层 的 BpBinder 


} 
// 返 回 Java 的 时 候 该 对 象 就 已 经 可 用 


return object; 


18.2 ”Binder 驱动 


对 象 识别 最 关键 一 点 是 区 分 出 其 所 属 进程 ， 这 是 内 核 层面 的 工作 ，Binder 协议 的 核心 
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是 由 Binder 内 核 驱动 实现 的 。 在 Binder 驱动 中 ,每 个 进程 的 对 象 被 组 成 一 棵 树 ， 之 间 存 在 
互相 引用 。 通 过 解析 接受 到 对 象 是 否 在 其 树 中 决定 是 本 地 对 象 还 是 远程 对 象 。 


18.2.1 Binder 与 


有 多 种 时 机 如 Binder 对 象 的 引用 发 生 时 , 有 新 的 线程 加 入 或 退出 Binder 协议 都 会 触发 
Binder 写 。 这 些 情 况 或 者 对 架构 影响 不 大 或 者 仅仅 是 维护 Binder 协议 本 身 的 动作 ， 本 书 不 
做 过 多 展开 。 下 面 着 重 分 析 当 远程 代理 对 象 发 起 对 本 地 对 象 调用 时 产生 的 Binder 写 ， 这 是 
Binder 对 象 机 制 以 及 Android 线程 模型 至 关 重 要 的 地 方 。 


/* 当 远程 代理 对 象 调用 本 地 对 象 ， 或 者 向 servicemanager 注册 对 象 或 者 查询 对 象 时 ， 该 函数 被 
调用 ， 触 发 命名 为 BC_TRANSACTION。 这 里 struct binder proc *proc 和 struct 
binder thread *thread 分 别 代表 发 起 BC_TRANSACTION 的 进程 和 线程 */ 
int binder thread write (struct binder proc *proc, struct binder thread 
*thread, 

void _user *buffer, int size, signed long *consumed) 


while (ptr < end && thread->return error == BR OK) { 
// 从 用 户 态 获得 命令 
if (get user(cmd, (uint32 t _ user *)ptr)) 
return -EFAULT; 


switch (cmd) { 


/* BC_TRANSACTION 远程 代理 的 调用 动作 ，BC_REPLY 对 应 本 地 对 象 的 函数 返回 写 动 
作 ， 分 别 是 不 同 进程 的 先后 写 */ 
case BC_TRANSACTION: 
case BC REPLY: { 
struct binder transaction data tr; 
// 将 用 户 空间 的 struct binder transaction_data 参数 取出 来 
if (copy_ from userl(&tr, ptr, sizeof (tr))) 
return -EFAULT; 
ptr += sizeof (tr); 
//Binder 核心 ， 对象 与 进程 的 区 分 都 在 这 里 进行 
binder _ transaction (proc, thread, &tr, cmd == BC REPLY); 


break; 


} 


return 0; 
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每 个 Binder 本 地 对 象 ,无 论 是 C++ 还 是 Java 层面 , 其 在 内 核 都 用 一 个 struct binder node 
唯一 对 应 。 每 个 进程 的 所 有 struct binder node 组 成 一 棵 树 。 若 要 用 代理 对 象 访问 跨 进程 的 
本 地 对 象 ， 则 代理 对 象 所 在 进程 的 底下 必 先 生成 其 引用 结构 struct binder ref。 


/*struct binder transaction data*tr 为 transaction 交易 参数 ，reply 表示 其 方向 */ 
static void binder transaction(struct binder proc *proc, 
struct binder thread *thread, 


struct binder transaction data *tr, int reply) 


if (reply) { 
// 不 考虑 应 答 方向 ， 理 解 了 调用 方向 ， 应 答 方向 自然 迎刃而解 
} else { 
/*target 为 远程 对 象 ，target .handle 为 远程 对 象 的 句柄 */ 
if (tr->target.handle) { 
struct binder ref *ref; 
// 在 struct binder_ref 树 中 查找 远程 
ref = binder get ref(proc, tr->target.handle); 
i€ (ref == WULLY { 
/* 在 实现 调用 之 前 ， 必 先 建 立 其 struct binder_ref， 若 找 不 到 引用 ， 接 
下 来 无 法 进行 */ 
// 远 程 本 地 对 象 
target node = ref->node; 
} else { 
// 若 远程 对 象 句柄 为 0， 这 个 远程 对 象 就 是 BINDER_SERVICE MANAGER 


target node = binder context mgr node; 
} 
/* 早 期 Binder 不 限制 调用 权限 ， 这 其 实 是 个 安全 漏洞 ， 使 得 系统 组 件 通过 Binder 暴露 


给 所 有 应 用 ， 后 期 的 Android 加 入 了 Binder 安全 机 制 */ 
if(security binder transaction(proc->tsk, target proc->tsk) < 0) { 
} 

if (!(tr->flags & TF ONE WAY) && thread->transaction stack) { 


/* 若 要 双向 交互 则 要 使 用 transaction _ stack， 为 简单 起 见 略 去 这 种 情况 */ 


} 
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/* 在 内 核 里 分 配 struct binder transaction*/ 
t = kzalloc(sizeof (*t), GFP KERNEL) 
/* 初 始 化 struct binder transaction 基本 参数 */ 
t->sender euid = proc->tsk->cred->euid; 
// 指 出 transaction 对 应 进程 
t->to proc = target proc; 
t->to thread = target thread; 
// 指出 transaction 对 应 的 函数 
t->code = tr->code; 
t->flags = tr->flags; 
t->priority = task nicel(current); 


// 分 配 transaction 的 buffer 
t->buffer = binder alloc buf (target proc, tr->data size, 
tr->offsets size, !reply && (t->flags & TF_ ONE WAY)); 


// 用 户 打 包 的 对 象 信息 地 址 

offp = (size t *) (t->buffer->data + ALIGN (tr->data size, sizeof (void 
“yz 

// 复 制 用 户 态 携带 信息 

if (copy_from user(t->buffer->data, tr->data.ptr.buffer, tr->data_ 
size)) { 

} 

// 复 制 用 户 态 对 象 信息 


if (copy_from user(offp, tr->data.ptr.offsets, tr->offsets size)) { 


off end = (void *)offp + tr->offsets size; 
/* 从 应 用 发 下 来 的 数据 包 里 依次 取出 每 个 对 象 并 进行 分 析 */ 
for (; offp < off end; offp++) { 

struct flat binder object *fp; 


/*fp 为 对 象 描述 结构 的 头 指针 */ 
fp = (struct flat binder object *) (t->buffer->data + *offp); 
switch (fp->type) { 
case BINDER TYPE BINDER: 
case BINDER TYPE WEAK BINDER: { 
/* 如 果 该 Binder 是 BINDER_TYPE_BINDER 或 BINDER_TYPE_WEAK BINDER 类 型 ， 
那么 对 于 当前 进程 ， 该 Binder 对 象 必定 是 本 地 对 象 */ 
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struct binder ref *ref; 

/* 在 内 核 层 查找 本 地 对 象 的 对 象 数据 结构 struct binder node*/ 
struct binder node *node = binder get node (proc, fp->binder); 
if (node == NOLL)Y 1 
/* 内 核 第 一 次 看 到 该 对 象 ， 比 如 在 addservice 时 ， 生 成 本 地 对 象 的 对 象 数 据 结 
构 struct binder node 并 加 入 本 地 对 象 树 中 */ 


node = binder new node(proc, fp->binder, fp->cookie); 
} 


// 安 全 检查 
if (security binder transfer binder(proc->tsk, target proc-> 
tsk)) { 
return error = BR FAILED REPLY; 
goto err binder get ref for node failed; 

/* 既 然 该 对 象 是 当前 线程 的 本 地 对 象 ， 那 对 于 target_proc 来 说 就 是 远程 对 象 ， 生 
成 属于 target_proc 引用 结构 并 加 入 其 引用 树 。struct binder_ref 代表 一 个 
Binder 的 跨 进程 引用 ， 一头 连 着 该 Binder 的 node， 一 头 连 着 对 方 近 的 struct 
binder_proc 结构 。 而 每 个 进程 对 另外 一 个 进程 里 的 Binder 对 象 的 引用 的 索引 
也 是 在 这 里 编号 的 。struct binder_ref 成 员 变量 desc 随 着 进程 中 跨 进程 引用 
的 增加 而 增加 ， 这 个 数值 就 是 BpBinder 的 handle */ 


ref = binder get ref for node(target proc, node); 


/* 如 果 该 对 象 在 当前 进程 是 BINDER_TYPE_BINDER 或 BINDER TYPE WEAK_ 
BINDER 类 型 ， 说 明 该 对 象 是 当前 进程 的 本 地 对 象 ， 那 么 对 于 目标 进程 ， 该 Binder 
对 象 必 定 是 远程 对 象 */ 
if (fp->type == BINDER TYPE BINDER) 

fp->type = BINDER TYPE HANDLE; 
else 
fp->type = BINDER TYPE WEAK HANDLE; 

// 该 对 象 在 目标 进程 的 句柄 号 
fp->handle = ref->desc; 
binder inc ref(ref, fp->type == BINDER TYPE HANDLE, 

&thread->todo); 


} break; 
/* 如 果 该 Binder 是 BINDER_TYPE_HANDLE 或 BINDER_TYPE_WEAK_HANDLE 类 型 ， 
那么 对 于 当前 进程 ， 该 Binder 对 象 必定 是 远程 对 象 */ 
case BINDER TYPE HANDLE: 
case BINDER TYPE WEAK HANDLE: { 
/* 婚 然 是 proxYy， 必 定 事前 已 经 建立 了 引用 ， 用 该 proxy 的 handle 去 该 进程 的 引 
用 树 里 去 查 相应 的 引用 结构 struct binder ref*/ 
struct binder ref *ref = binder get ref(proc, fp->handle); 


if (ref = NULL) { 


tsk)) 


{ 
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/* 根 据 binder 协议 ， 不 会 出 现 这 种 情况 ， 否 则 出 错 */ 
return error = BR FAILED REPLY; 
goto err binder get ref failed; 
} 
// 安 全 检查 


if (security binder transfer binder (Proc->tsk，target_Proc-> 


return error = BR FAILED REPLY; 
goto err binder get ref failed; 

} 

/* 根 据 引 用 找到 对 应 的 node， 青 根据 node 找到 该 Binder 实现 的 进程 */ 
if (ref->node->proc == target proc) { 

/* 该 node 的 实现 进程 就 是 本 次 transaction 的 目标 进程 ， 该 Binder 对 象 在 
目标 进程 为 本 地 对 象 ， 将 其 类 型 改 为 BINDER_TYPE_BINDER 和 BINDER_ 
TYPE WEAK BINDER*/ 

if (fp->type == BINDER TYPE HANDLE) 
fp->type = BINDER TYPE BINDER; 

else 
fp->type = BINDER TYPE WEAK BINDER; 


/*struct binder_node 的 成 员 变量 cookie 记载 着 该 Binder 在 用 户 态 的 地 
址 ， 返 回 到 用 户 态 直接 引用 指针 即 可 */ 
fp->binder = ref->node->ptr; 
fp->cookie = ref->node->cookie; 

/* 修 改 引用 计数 */ 
binder inc node (ref->node, fp->type == BINDER TYPE BINDER, 
0, NULL); 


} else { 

/* 这 是 最 复杂 的 情况 ， 设 当前 进程 为 A，transaction 的 target 进程 为 B， 而 
Binder 的 本 地 实现 及 Bbinder 在 进程 C。 某 个 进程 去 servicemanager 查 
找 某 个 service 就 是 这 种 情况 */ 

struct binder ref *new ref; 
/* 在 目标 进程 里 寻找 该 Binder 的 引用 结构 */ 
new_ref = binder get ref for node(target proc, ref-> 
node); 
if (new ref == NULL) { 
/* 找 不 到 说 明 不 符合 Binder 协议 ， 系 统 报错 */ 
return error = BR FAILED REPLY; 
goto err binder get ref for node failed; 
} 

/* 尽 管 该 对 象 的 node 节点 只 有 一 个 , 但 是 引用 在 不 同 的 进程 都 是 独立 的 , 找到 了 
该 对 象 在 target 进程 的 引用 ， 自 然 就 取得 了 其 handle 值 */ 

fp->handle = new ref->desc; 


/* 修 改 引 用 计数 */ 
binder inc ref(new ref, fp->type == BINDER TYPE HANDLE, 
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NULL); 


} 
} break; 


case BINDER TYPE FD: { 
/*File 类 型 ， 用 来 在 两 个 进程 中 共享 一 个 文件 ， 而 共享 文件 意味 着 map 到 该 file 
的 内 存 的 共享 ， 用 户 进程 与 surfaceflinger 之 间 的 内 存 共享 就 是 通过 这 种 方式 
实现 的 */ 
int target fd; 
struct file *file; 


// 在 目标 进程 的 文件 描述 符 表 中 分 配 一 项 
target fd = task get unused fd flags(target proc, O CLOEXEC); 


/* 将 file 安装 在 文件 描述 符 表 中 ， 这 样 把 fd 传 上 去 ， 用 户 层 就 能 使 用 该 文件 了 */ 
task fd install (target proc, target fd, file); 
trace binder transaction fdl(t, fp->handle, target fd); 
// 这 个 handle 即 为 句柄 
fp->handle = target fd; 
} break; 


} 


// 目 标 进 程 的 Binder 读 时 会 发 现 一 个 BINDER_WORK_TRANSACTION 待 处 理 
t->work.type = BINDER WORK _ TRANSACTION; 
list add tail (gt->work.entry, target list); 


return; 


18.2.2 Binder 读 


DVM 的 线程 池 线程 趴 在 Binder 上 ， 等 待 有 内 容 从 内 核 传递 上 来 。Binder 读 要 处 理 
Binder 协议 的 各 种 命令 , 而 最 关键 的 远 端 代理 对 象 发 起 BC_ TRANSACTION 时 ,本 地 对 象 
的 Binder 读 的 相应 动作 。 


/*struct binder proc *proc 代表 本 地 对 象 所 在 进程 ，struct binger thread *thread 
代表 当前 线程 池 线程 */ 
static int binder _ thread _read (struct binder Proc *proc, 

struct binder _ thread *thread, 

Void User buffer, int size; 


signed long *consumed, int non block) 
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while (1) { 
/* 从 Binder 写 一 节 可 以 看 出 , 远 端 代理 对 象 线程 发 起 BC_TRANSACTION 时 ,已 将 需要 本 
地 对 象 所 在 线程 池 线 程 处 理 的 工作 挂 在 了 thread->todo 上 */ 
if (!list empty(&thread->todo)) 
w= 1ist first entry(gthread->todo, struct binder work, entry); 


switch (w->type) { 
// 对 方 通过 Binder 写 提 交 了 一 个 BINDER_WORK_TRANSACTION 工作 
case BINDER WORK TRANSACTION: { 
t = container of(w, struct binder transaction, work); 
} break; 


//buffer->target_node 为 本 地 待 调 用 对 象 
if (t->buffer->target node) { 
struct binder node *target node = t->buffer->target node; 
/*cookie 即 为 其 bbinder 指针 ， 上 层 线程 池 线 程 取出 该 指针 直接 就 可 以 执行 
onTransact*/ 
trstarget ptr = target node->ptr; 
tr.cookie = target node->cookie; 
t->saved priority = task nice(current); 
// 指 定 命令 为 BR_TRANSACTION 
cmd = BR_ TRANSACTION; 
} else { 
} 
// 指 定 调用 功能 函数 
tr.code = t->code; 


tr.data size = t->buffer->data size; 
trsoffasets size = t->buffer->offsets sizes 
tr.data.ptr.buffer = (void *)t->buffer->data + 


proc->user buffer offset; 


// 将 命令 和 traction 数据 包 发 到 用 户 态 */ 
if (put user(cmd, (uint32 t _ user *)ptr)) 
return -EFAULT; 
ptr += sizeof (uint32 t); 
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if (copy to userl(ptr, é&tr, sizeof (tr))) 
return -EFAULT; 


break; 


return 0; 


18.3 ”C++ 层面 


18.3.1 本 地 与 远 端 对 象 


根据 本 地 还 是 远程 对 象 ，C++ 层 有 着 不 同 的 封装 形式 ， 本 节 讨论 这 些 在 C++ 层面 本 地 
与 远 端 对 象 的 封装 的 实现 。 


1. 本 地 封装 


(1) 本 地 Binder。 


class BBinder : public IBinder 


{ 
public: 


/*interface 描述 符 */ 


Virtual const Stringl16& getInterfaceDescriptor () const; 


/* 接 受 远 端 proxy 的 调用 */ 

virtual status t onTransact( uint32 t code, 
const Parcel& data, 
Parcel* reply, 
uint32 t flags = 0); 


: 


(2) 本 地 服务 都 从 class BnlInterface 继承 而 来 ， 本 地 服务 最 重要 的 是 重 载 函 数 virtual 
status_t onTransact( ..);， 远 端 proxy 的 调用 都 通过 该 函数 进来 。 


template<typename INTERFACE> 
class BnInterface : public INTERFACE, public BBinder 
{ 


public: 
virtual sp<IInterface> queryLocalInterface(const String16& 
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_descriptor); 
}; 


2. proxy 封装 


class BpRefBase : public virtual RefBase 


{ 
protected: 


/* 远 端 binder 对 象 ， 对 远 端 服务 对 象 的 调用 都 是 依据 mRemote 进行 的 */ 


inline IBinder* remote () { return mRemote; } 


IBinder* const mRemote; 


} 
远 端 代理 需要 继承 class BpInterface， 代 码 如 下 : 


template<typename INTERFACE> 
class BpInterface : public INTERFACE, public BpRefBase 
{ 
public: 
BpInterface(const sp<IBinder>& remote); 


}; 


无 论 是 class BnInterface 还 是 class BpInterface 都 继承 于 某 个 服务 的 INTERFACE。 所 
有 服务 实现 自己 的 INTERFACE 都 必须 遵循 以 下 做 法 : 

(1) 继承 自 class IInterface。 

(2) 实现 descriptor 和 asInterface 函数 。 

实际 上 每 个 服务 的 INTERFACE 在 自己 的 类 定义 里 引用 宏 。 

DECLARE_META _INTERFACE(INTERFACE) 声 明 descriptor 和 asInterface 函数 。 而 这 
两 个 函数 的 实现 是 通过 宏 IMPLEMENT _ META INTERFACE(INTERFACE, NAME) 完 成 
的 。 这 两 个 宏 的 定义 位 于 frameworks/base/include/binder/IInterface.h。 

其 中 asInterface 函数 是 关键 ,进一步 分 析 其 实现 ， 代 码 如 下 : 


android::sp<I##INTERFACE> I##INTERFACE: :asInterface( 
const android::sp<android::IBinder>& obj) 


android: :sp<I##INTERFACE> intr; 
if (obj != NULL) { 
intr = static cast<I##INTERFACE*>( 
obj->queryLocalInterface( 
I##INTERFACE: :descriptor) .get ()); 
if (intr == NULL) { 


a i 
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intr = new Bp##INTERFACE (obj); 


} 


return intr; 


WR 


. 


这 里 参数 obj 的 类 型 或 者 是 class BBinder 或 者 是 class Bpinder。 如 果 是 class BBinder， 
则 该 指针 就 是 class BnInterface 的 指针 , 其 queryLocalInterface 函数 已 经 被 重 载 , 代码 如 下 : 


template<typename INTERFACE> 
inline sp<IInterface> BnInterface<INTERFACE>::queryLocalInterface( 
const Stringl6& descriptor) 
{/* 如 果 就 是 自己 的 接口 描述 符 ， 则 返回 自己 的 指针 */ 
if ( descriptor == INTERFACE::descriptor) return this; 
return NULL; 
} 


但 是 如 果 是 class Bpinder 类 型 ， 其 queryLocalInterface 一 直 没 重 载 还 是 class IBinder 
的 实现 ， 代 码 如 下 : 
sp<IInterface> IBinder::queryLocalInterface (Const Stringl6& descriptor) 
{  /* 返 回 空 值 */ 
return NULL; 
. 


如 果 返 回 NULL， 则 生成 一 个 Bp 机 INTERFACE 类 型 的 对 象 ， 这 是 一 个 远 端 proxy。 
值得 关注 的 是 Bp 埠 INTERFACE 类 型 的 对 象 的 mRemote， 指 向 其 对 应 的 BpBinder。 


///BpBiner 的 transact 接力 
status t BpBinder::transact( 
uint32 t code, const Parcelg data, Parcel* reply, uint32 t flags) 


// Once a binder has died, it will never come back to life. 
if (mAlive) { 
/* 远 程 调用 ，mHandle 标识 调用 指向 的 对 象 ，code 为 调用 的 功能 ， data 为 调用 参数 ，reply 
为 返回 结果 */ 
Status t status = IPCThreadstate::self()->transact( 
mHandle, code, data, reply, flags); 
if (status == DEAD OBJECT) mAlive = 0; 


return status; 


return DEAD OBJECT; 
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18.3.2 ”服务 的 建立 


本 节 分 析 Service 与 ServiceManager 之 间 的 关系 ,包括 Service 的 ServiceManager 代理 
的 获取 ， 及 通过 该 代理 的 注册 动作 。 


1. DefaultServiceManager 的 获取 


所 有 服务 都 被 ServiceManager, 系统 中 需要 使 用 某 个 服务 时 , 首先 要 问 ServiceManager 
申请 : 
sp<IServiceManager> defaultServiceManager () 


{ 
/*defaultServiceManager 的 结果 放 在 gDefaultServiceManager， 如 果 已 经 取得 


defaultServiceManager 直接 返回 */ 
if (gDefaultServiceManager != NULL) return gDefaultServiceManager; 


{ 


/* 第 一 次 取 defaultServiceManager */ 
if (gDefaultServiceManager == NULL) { 
/*asInterface 函数 根据 BpBinder 生成 class BpServiceManager 的 对 象 */ 


gDefaultServiceManager = interface cast<IServiceManager>( 
/* 因 为 ServiceManager 单独 在 一 个 进程 实现 ， 所 以 这 里 返回 的 必定 是 BpBinder*/ 
ProcessState: :self ()->getContextObject (NULL) ); 


} 


return gDefaultServiceManager; 


} 
2. ServiceManager 的 BpBinder 对 象 生成 


sp<IBinder> ProcessState::getContextObject (const sp<IBinder>& caller) 
{ /* 查 找 handle 号 为 0 的 IBinder*/ 

return getstrongProxyForHandle (0); 
. 


3. 服务 注册 


服务 首先 需要 使 用 class BpServiceManager:: addService 向 serveicemanager 注册 自己 ， 
代码 如 下 : 


virtual status t addService (const String16& name, const SP<IBinder>& 


service) 


{ 
Parcel data, reply; 
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data.writeInterfaceToken (IServiceManager: :getInterfaceDescriptor ()); 

/* 服 务 名 */ 

data.writeStringl6 (name); 

/* service 为 自己 的 BnXXX 对 象 */ 

data.writeStrongBinder (service); 

/*BpBinder 的 transact 函数 */ 

status t err = remote()->transact (ADD SERVICE TRANSACTION, data, 
&reply); 

return err == NO ERROR ? reply.readExceptionCode() : err; 


18.4 Java 层面 


本 地 对 象 代理 对 象 在 Java 与 C++ 层 的 概念 完全 一 样 。Java 层 的 每 个 本 地 对 象 和 代理 对 
象 在 C++ 层 都 有 着 唯一 对 应 的 对 象 。 所 有 与 Binder 协议 底层 相关 的 操作 都 是 通过 这 些 C++ 
层 的 对 应 对 象 实现 的 ， 然 后 通过 Java 与 JNI 的 进出 机 制 与 Java 层 对 象 进行 交互 。 

Java 层 本 地 对 象 如 下 : 


public class Binder implements IBinder { 


// 线 程 池 入 口 


public static final native void joinThreadPool (); 
private native final void init(); 


// 线 程 池 线程 从 这 里 进入 Java 层 
private boolean execTransact (int code, int dataObj, int replyObj, 
int flags) { 


try { 
// 调 用 onTransact 函数 ， 功 能 类 通常 会 重 载 onTransact 


res = onTransact (code, data, reply, flags); 
) -cateh ee) { 


在 JNI 层 有 一 个 class JavaBBinderHolder 类 ， 它 维护 一 个 class JavaBBinder : public 
BBinder 类 型 的 对 象 ， 该 对 象 是 Java 层 本 地 对 象 在 C++ 层 的 对 应 对 象 ， 线 程 池 通 过 这 个 对 
象 访问 Java 层 。 而 内 核 识别 对 象 和 引用 也 是 通过 该 对 象 。 


//Java 层 代 理 对 象 
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final class BinderProxy implements IBinder { 


// 功 能 类 将 调用 该 函数 以 实现 远程 调用 
public native boolean transact(int code, Parcel data, Parcel reply, 


int flags) throws RemoteException; 


} 


首先 在 Java 获得 Parcel 以 后 ， 使 用 readStrongBinder 来 获得 其 中 的 对 象 。 
readStrongBinder 通过 native 函数 nativeReadStrongBinder 在 C++ 层 解 包 ， 这 样 就 获得 了 该 
对 象 的 BpBiner。 接 着 nativeReadStrongBinder 调用 JNI 层 的 newobject， 创 建 Java 层 class 
BinderProxy 对 象 。 JIN 在 创建 Java 层 class BinderProxy 对 象 是 以 先前 创建 的 Bpbinder 做 参 
数 ， 并 在 class BinderProxy 对 象 的 mObject 位 置 处 记 下 这 个 BpBinder。 这 样 BpBinder 自然 
与 class BinderProxy 对 应 起 来 。 

以 后 每 次 class BinderProxy 调用 transact 找到 BpBinder， 从 而 发 起 C++ 层 transact。 


18.5 service_ manager 


首先 ，service_manager 是 一 个 单独 的 进程 ， 早 期 的 Android 版 本 是 用 Java， 由 于 这 个 
地 方 的 交互 十 分 频繁 ， 所 以 后 来 改 成 C 的 。 

service_manager 位 于 frameworks/base/cmds/servicemanager/service manager.c 中 。 它 负 
责 管 理 系统 中 所 有 的 service， 它 调用 int binder become_ context manager(…) 问 内 核 申 明 自 
己 就 是 Servicemanager。 

事实 上 service_manager 进程 本 身 没 有 太 多 导 辑 功能 , 真正 的 作用 在 于 内 核 在 其 底部 维 
护 所 有 service 的 引用 ， 这 样 在 以 后 的 进程 查找 service 时 ， 内 核 就 通过 service_manager 进 
程 下 的 引用 树 ， 找 到 其 节点 所 在 的 进程 。 就 逻辑 实现 上 service_ manager 可 以 作为 系统 线程 
存在 ， 为 什么 单独 成 为 一 个 进程 ? 这 里 就 是 答案 。 

观察 Java 层 的 ServiceManager 就 可 以 发 现 大 量 的 native 函数 , 具体 分 析 其 实现 就 可 以 
发 现 class ServiceManager 其 实 指 向 service_ manager 进程 的 ，Java 层 的 类 注册 、 查 询 服务 
还 是 通过 service_manager 进程 实现 的 ， 或 者 准确 地 说 是 service_manager 进程 下 的 那 棵 树 
实现 的 。 
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逻辑 上 来 看 ，Dalvik 虚拟 机 可 以 分 割 为 两 部 分 ， 一 部 分 是 内 核 的 延伸 ， 如 内 存 机 制 延 
伸 为 Java 堆 的 构建 ， 对 象 的 分 配 与 GC、 进 线程 机 制 延 伸 为 以 解释 器 为 中 心 的 线程 机 制 。 
另 一 部 分 就 是 类 机 制 ， 大 量 的 类 库 不 仅 为 Java 进程 提供 存储 、 网 络 通信 等 基础 功能 ， 而 且 
通过 类 库 内 部 的 有 机 设计 ， 提 供 了 Java 进程 的 应 用 框架 。 


19.1 系统 类 库 


19.1.1 Inital class 


Inital class 是 Java 语言 里 最 基础 的 类 ,Dalvik 系统 库 构 建 的 第 一 个 工作 是 构建 支持 Java 
语言 基本 类 型 的 Inital class， 这 些 基础 类 列表 如 下 所 示 : 

(1) Ljava/lang/Class; 

(2) Ljava/lang/Boolean:,Ljava/lang/Character:,Ljava/lang/Float;,Ljava/lang/Double:,Ljava/ 
lang/Byte;,Ljava/lang/Short;,Ljava/lang/Integer;,Ljava/lang/Long;: 

这 些 类 不 是 从 类 文件 中 加 载 ， 而 是 默认 集成 进 Dalvik 运行 时 ， 且 在 较 早 的 阶段 完成 。 


static bool createInitialClasses() { 


//class Class 对 象 的 生成 
ClassObject* clazz = (ClassObject*) 
dvmMalloc (classObjectSize (CLASS_ SFIELD SLOTS), ALLOC NON MOVING); 


DVM OBJECT INIT(clazz, clazz); 

SET_CLASS FLAG (clazz, ACC_ PUBLIC | ACC FINAL | CLASS _ ISCLASS); 

clazz->descriptor = "Ljava/lang/Class;"; 

/* 在 struct DvmGlobals gDvm; 的 classJavaLangClass 里 记录 这 个 代表 class Class 
的 classObject*/ 


gDvm.classJavaLangClass = clazz; 
//Java 里 面 Void Byte 等 原始 类 型 的 Classobject 的 生成 
bool ok = true; 


/* 在 struct DvmGlobals gDvm; 的 classJavaLangClass 里 记录 这 个 代表 Void 的 
ClassObject*/ 
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ok &= createPrimitiveType (PRIM VOID, &gDvm.typeVoid); 
/* 在 struct DvmGlobals gDvm; 的 classJavaLangClass 里 记录 这 个 代表 Boolean 的 
ClassObject*/ 
ok &= createPrimitiveType (PRIM BOOLEAN, &gDvm.typeBoolean); 


return ok; 


} 


以 上 工作 只 是 初始 化 了 Inital class， 但 是 还 并 未 将 其 加 载 到 DVM 类 管理 基础 设施 中 。 
这 里 只 是 初始 化 这 些 class 并 记录 在 DVM 全 局 变量 中 。 真 正 加载 工 作 在 static bool 
initClassReferences0: 和 bool dvmValidateBoxClasses() 里 完成 。 


19.1.2 ODEX 文件 的 加 载 


尽管 JAR 文件 是 常见 的 类 库 文件 ， 但 这 是 个 压缩 文件 ，Davik 真正 使 用 的 是 经 过 解压 
优化 过 之 后 的 ODEX 文件 ,在 Android 系统 类 库 目 录 system/framework 下 , 每 个 JAR 类 库 
都 对 应 一 个 ODEX 文件 。 

ODEX 文件 的 加 载 有 两 个 方面 的 动作 : 首先 是 文件 通过 映射 方式 加 载 ， 这 种 方式 的 好 
处 是 仅 在 访问 时 才 会 启动 磁盘 操作 ， 且 代码 段 可 共享 page cache， 参 见 本 书 内 核 部 分 分 析 ; 
第 二 个 动作 是 文件 结构 的 解析 ， 由 于 ODEX 文件 已 经 经 过 优化 ,其 解析 主要 完成 地 址 重地 
位 即 可 。 

//ODEX 文件 映射 主体 

int dvmDexFileOpenFromFd(int fd, DvmDex** ppDvmDex) 

{ 


// 文 件 映射 建立 File backed 类 型 的 虚拟 内 存 
if (sysMapFileInShmemWritableReadOonly(fd, gmemMap) != 0) { 


3 


// 解 析 ， 完 成 地 址 重 定位 
pDexFile = dexFileParse((ul*)memMap.addr, memMap.length, parseFlags); 


// 生 成 struct DvmDex，Dalvik 运行 直接 面 对 的 类 库 文件 结构 


pDvmDex = allocateAuxStructures (pDexFile); 


} 
//odex 文件 的 映射 
int sysMapFileInShmemWritableReadOnly (int fd, MemMapping* pMap) 


{ 


// 最 关键 的 操作 ， 读 写 型 MAP_PRIVATE 映射 ， Android 系统 最 主要 的 映射 方式 
memPtr = mmap(NULL, length, PROT READ | PROT WRITE, MAP FILE | 
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MAP_ PRIVATE, 
Fd Start}s 


return 0; 


} 


19.1.3 ”系统 类 库 


在 Android 运行 时 ， 初 始 化 函数 dvmStartup 中 调用 基础 类 库 的 初始 化 函数 bool 
dvmClassStartup()。 该 函数 在 做 完 Ljava/lang/Class; 类 及 primitive types 类 的 初始 化 之 后 初始 
基础 类 库 ， 基 础 类 库 被 记录 在 gDvm.bootClassPathStr 中 ，gDvm.bootClassPathStr 有 以 下 两 
种 指定 方式 。 

(1) 在 dalvilyvmyinitcpp 里 ， 通 过 提取 环境 变量 取得 。 

static void setCommandLineDefaults () 


i 
// 提 取 环 境 变 量 "BOOTCLASSPATH" 
envSstr = getenv ("BOOTCLASSPATH"); 


(2) 在 创建 DVM 虚拟 机 时 通过 添加 -Xbootclasspath 参数 指定 。 

将 -Xbootclasspath 添加 到 jint JNI CreateJavaVM(JavaVM** p_vm, JNIEnv** p_env, 
Void* vm_args) 人 的 参数 数组 void* vm_args。 这 将 在 虚拟 机 创建 过 程 的 int processOptions(int 
argc，const char* const argv[]， bool ignoreUnrecognized) 环 境 中 被 分 析出 来 ， 并 指定 给 
gDvm.bootClassPathStr。 

系统 类 库 包 含 如 下 文件 (以 “:” 做 分 割 ): 

/system/framework/core.jar:/system/framework/core-junit.jar:/system/fra 

mework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/fra 

mework.jar:/system/framework/telephony-common.jar:/system/framework/mms 

-common.jar:/system/framework/android.policy.jar:/system/framework/serv 


ices.jar:/system/framework/apache-xml .jar 


事实 上 ,以 上 类 库 文件 都 有 其 对 应 的 ODEX 优化 文件 ，Dalvik 其 实 是 加 载 这 些 ODEX 
文件 。 基 础 类 库 的 使 用 经 过 两 个 阶段 : 第 一 个 阶段 是 预 处 理 ， 第 二 个 阶段 是 真正 的 加 载 。 
而 Android 系统 将 经 常 使 用 的 类 单独 统计 出 来 ， 在 zygote 初始 化 时 就 将 这 些 类 预 加 载 到 
DVM 管理 机 构 。 这 样 在 fork 新 的 Java 进程 时 这 些 预 加 载 的 类 库 得 到 共享 。 而 那些 非 预 加 
载 的 类 库 ，Java 进程 使 用 时 才 进 行 加 载 ， 尽 管 这 些 类 库 的 代码 因为 page cache 机 制 得 到 内 
存 共享 ， 但 是 这 些 类 库 在 DVM 中 的 管理 机 构 却 不 是 共享 内 存 的 。 

本 节 分 析 第 一 个 阶段 一 一 预 处 理 。 


/ /基础 类 库 预 处 理 函 数 
static ClassPathEntry* processClassPath(const char* pathStr, bool 
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isBootstrap) 


下 


/# 为 每 一 个 基础 类 库 文件 开 出 一 个 ClassPathEntry， 形 成 一 个 数组 : ClassPathEntry* 
cpe*/ 
cpe = (ClassPathEntry*) calloc(count+1, sizeof (ClassPathEntry)); 


// 记 录 这 个 数组 在 gDvm.bootclassPath 中 
gDvm.bootClassPath = cpe; 


while (cp < end) { 


// 处 理 每 一 个 FrameWork 类 文件 ， 这 里 只 做 map 动作 
prepareCpe (&tmp, isBootstrap) 


} 


这 样 基础 类 库 被 整理 到 gDvm.bootClassPath， 以 后 加 载 基础 类 库 里 的 类 从 这 里 寻找 即 
可 , 而 对 于 基础 类 库 本 身 预 处 理 实现 其 内 存 映射 ,在 zygote 生成 新 的 Java 进程 被 集成 下 来 ， 
所 以 每 个 Java 进程 中 基础 类 库 的 映射 地 址 都 相同 ， 如 下 所 示 。 


库 文件 名 映射 起 始 地 址 映射 长 度 
/system/framework/core.odex 45c4b000 350910 
/system/framework/core-junit.odex 45fd7000 6bb8 
/system/framework/bouncycastle.odex 45fe0000 108720 
/system/framework/ext .odex 4610d000 16f550 
/system/framework/framework.odex 4629b000 9f11d8 
/system/framework/telephony-common.odex 46d4f000 121ac0 
/system/framework/mms-common .odex 46e89000 1fc58 
/system/framework/android.policy.odex 46ead000 9b4d0 
/system/framework/services.odex 46f58000 291e60 
/system/framework/apache-xml .odex 47218000 150920 


以 上 映射 地 址 仅 供 参 考 ， 由 于 Android 系统 的 版 本 不 同 ， 这 些 地 址 也 会 有 所 不 同 。 以 
上 为 Android 4.0 版 本 上 的 映射 。 


19.1.4 preloaded-classes 


基础 类 库 是 为 了 支持 基本 Java 语言 的 运行 ， 对 于 Android 系统 ， 除 了 基础 类 库 以 外 ， 
应 用 框架 、UI 体系 以 及 大 量 功 能 性 组 件 ， 都 是 以 类 库 形式 出 现 的 ， 且 其 中 有 相当 数量 的 类 
库 被 普通 的 程序 大 量 使 用 , 为 了 提高 运行 效率 和 内 存 使 用 效率 , 需要 将 这 些 库 预 加 载 进 来 。 
这 些 常 用 库 就 称 为 preloaded-classes， 其 预 加 载 过 程 是 Android 系统 启动 主要 耗 时 所 在 。 
预 加 载 过 程 首 先 要 找 出 需要 找 出 那些 类 是 需要 预先 加 载 的 ， 代 码 如 下 : 


InputStream is = ZygotelInit.class.getClassLoader() .getResourceAsStream( 
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PRELOADED CLASSES) ; 


这 个 Java 语句 的 背后 动作 是 : 
(1) 调用 class Class 的 ClassLoader getClassLoader(); 函数 找到 class ClassLoader。 
(2) 得 到 的 class ClassLoader 是 class BootClassLoader。 
(3) 调用 class BootClassLoader 的 InputStream getResourceAsStream(String resName); 
去 找 InputStream。 其 中 顺序 如 下 : 
GD class BootClassLoader 自身 实现 的 URL getResource(String resName)。 
@ class BootClassLoader 自身 实现 的 URL findResource(String name)。 
@ class VMClassLoader 的 URL getResource(String name)。 
再 往 下 是 class VMClassLoader native 函数 实现 的 。 
抽象 地 看 ， 由 于 class BootClassLoade 继承 于 class ClassLoader， 这 里 的 动作 是 让 class 
ClassLoader 去 找到 需要 加 载 的 类 列表 。 该 类 列表 的 创建 和 寻找 机 制 参见 上 文 。 
class VMClassLoader 对 应 的 native 函数 如 下 : 
static URL getResource (String name) { 
/* 找 到 BootclassPath 有 多 少 个 文件 路 径 。 所 谓 BootclassPath 其 实 都 是 JAR 文件 ， 相 当 于 
文件 路 径 */ 
int numEntries = getBootClassPathSize(); 
// 针 对 每 一 个 文件 路 径 (JRR 里 ) 去 找 里 面 的 preloaded-classes 文件 
for (int i = 0; i < numEntries; i++) { 


String urlstr = getBootClassPathResource (name, i); 


} 


return null; 


class VMClassLoader native 函数 native private static String getBootClassPathResource 
(String name, int index); 的 实现 代码 如 下 : 
static void Dalvik java lang VMClassLoader getBootClassPathResource( 


const u4* args, JValue* pResult) 


result = dvmGetBootPathResource (name, idx); 


StringObject* dvmGetBootPathResource (Const char* name, int idx) 
{ 
Switch (cpe->kind) { 


case kCpeJar: 


{ 
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JarFile* pJarFile = (JarFile*) cpe->ptr; 
// 去 JAR 文件 包 里 找 preloaded-classes 文件 
if (dexZipFindEntry (gpJarFile->archive, name) == NULL) 
goto bail; 
// 该 JAR 包 里 有 要 找 的 preloaded-classes 文件 ， 记 录 该 目录 
sprintf (urlBuf, "jar:file://%s!/%s", cpe->fileName, name); 
} 


break; 


} 


// 给 Java 生成 返回 对 象 
urlobj = dvmCreateStringFromCstr (Url1Buf) 


bail: 
return urlObj; 


} 


而 preloaded-classes 类 库 明 细 的 定义 方式 是 : 在 /system/framework/framework.jar 存放 
着 一 个 名 为 preloaded-classes 的 文件 ， 该 文件 记录 了 preloadClasses 时 需要 加 载 的 类 。 这 些 
类 是 经 过 统计 工具 得 出 的 最 常用 的 类 ， 原 始 文件 就 放 在 Android 源码 的 
frameworks/base/preloaded-classes 路 径 下 ， 编 译 时 被 打包 进 framework.jar。 

对 于 Android 4.0, preloaded-classes 文件 列举 出 的 类 数目 达到 2200 多 个 , 对 于 Android 
2.3， 该 文件 列举 出 的 类 数目 是 1800 多 个 。 由 此 可 以 理解 为 什么 最 初 的 Android 在 400M 
的 ARM9 跑 得 都 很 顺畅 ， 而 5 年 后 ， 这 个 级 别 的 处 理 器 跑 起 来 Android 4.0 却 相当 费力 。 


192 类 加 载 


Dalvik 虚拟 机 在 运行 时 需要 频繁 的 执行 生成 对 象 、 调 用 函数 等 操作 。 而 所 有 这 些 动作 
的 基础 都 依赖 于 类 。 所 以 虚拟 机 在 执行 与 某 个 类 相关 的 动作 之 前 要 充分 了 解 类 的 所 有 信息 ， 
这 个 过 程 就 是 类 加 载 。 


19.2.1 类 加 载 框架 


类 加 载 的 过 程 如 下 : 

(1) 指定 或 从 系统 类 库 里 找到 待 加 载 类 所 在 的 文件 ， 对 应 于 struct DvmDex, 然后 再 在 
该 文件 中 解析 出 该 类 类 定义 结构 struct DexClassDef， 这 相当 于 类 头 。 

(2) 从 类 文件 中 加 载 该 类 ,这 一 步 生 成 该 类 所 对 应 Dalvik 管理 结构 struct ClassObject。 

(3) 类 链接 ， 加 载 该 类 对 应 的 父 类 、 建 立 vtable 等 操作 。 


//Dalvik 类 加 载 的 框架 函数 
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static ClassObject* findClassNoInit (const char* descriptor, Object* loader, 


DvmDex* pDvmDex) 


/*Dalvik 将 加 载 的 类 都 加 入 在 其 hash 表 gDvm.1loadedclasses 中 ， 这 是 一 个 缓存 机 制 
先 在 其 中 查找 该 类 是 否 存在 */ 


clazz = dvmLookupClass (descriptor, loader, true); 


//hash 表 中 没有 该 类 ， 下 面 执行 加 载 动作 
if (clazz == NULL) { 


if (pDvmDex == NULL) { 

// 未 指定 类 的 加 载 目录 ， 在 系统 类 库 里 找 

pDvmDex = searchBootPathForClass (descriptor, &pClassDef); 
} else { 

// 指 定 了 该 类 所 在 文件 ， 则 直接 在 指定 文件 中 找 

pClassDef = dexFindClass (pDvmDex->pDexFile, descriptor); 


if (pDvmDex == NULL || pClassDef == NULL) { 
if (gDvm.noClassDefFoundErrorObj] != NULL) { 
/* 找 不 到 该 类 的 定义 ， 类 未 定义 异常 ， 交 给 应 用 程序 去 处 理 */ 
dvmSetException (self, gDvm.noClassDefFoundErrorObj); 
} else { 
/* 类 定义 异常 ， 可 能 是 文件 错误 ， 直 接 抛 出 异常 */ 
dvmThrowNoClassDefFoundError (descriptor); 
} 
goto bail; 
} 


/* 类 加 载 ， 这 里 产生 该 类 对 应 的 struct Classobject*/ 
clazz = loadClassFromDex (pDvmDex, pClassDef, loader); 


/* 接 下 来 其 他 线程 有 可 能 获得 该 struct Classobject， 但 还 没完 成 工作 ， 所 以 将 其 


起 来 */ 
dvmLockObject (self, (Object*) clazz); 
// 记 录 下 类 的 初始 化 线程 号 


clazz->initThreadId = self->threadId; 


/* 将 加 载 的 类 加 入 类 的 cache 哈 希 表 中 */ 
if (!dvmAddClassToHash (clazz)) { 
/* 有 另外 的 线程 抢先 一 步 加 载 该 类 ， 类 似 于 内 核 里 经 常 发 生 的 情况 */ 


clazz->initThreadId = 0; 


/ /释放 掉 不 必要 的 clazz 


锁 
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dvmFreeClassInnards (clazz); 


/* 取现 成 的 struct ClassObject 即 可 */ 
clazz = dvmLookupClass (descriptor, loader, true); 
goto got class; 


} 


// 类 链接 ， 参 见 下 文 
if (!'dvmLinkClass(clazz)) { 


// 链 接 失败 的 情况 ， 释 放 掉 该 类 
goto bail; 
} 


// 解 锁 该 struct Classobject， 其 他 的 线程 也 可 以 用 了 
dvmUnlockObject (self, (Object*) clazz); 


19.2.2 ”类 加 载 


类 加 载 并 不 是 把 类 从 文件 中 读 进 内 存 ， 而 是 生成 其 控制 结构 struct ClassObject， 并 解 
析 类 相关 成 员 变量 、 函 数 等 信息 。 

// 类 加 载 主题 函数 

static ClassObject* loadClassFromDex0 (…) 

{ 


// 为 该 类 分 配 struct Classobject 结构 
newClass = (ClassObject*) dvmMalloc (size, ALLOC NON MOVING); 


// 设 置 该 类 的 classloader 
SET_CLASS_FLRAG (newClass, pClassDef->accessFlags); 
dvmSetFieldObject ( (Object *)newClass, 


OFFSETOF _ MEMBER (ClassObject, classLoader), 
(Object *)classLoader); 


// 记 录 该 类 所 在 文件 struct DvmDex 
newClass->pDvmDex = pDvmDex; 


// 记 录 该 类 的 父 类 ， 在 类 链接 时 需要 解析 其 父 类 
newClass->super = (ClassObject*) pClassDef->superclassIdx; 


/* 在 解析 完 类 接口 、 类 静态 域 、 类 实例 域 之 后 解析 类 函数 ，DirectMethoqd 指 的 是 Java 里 的 
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static、private、<init> 函 数 */ 
if (pHeader->directMethodsSize != 0) { 
// 取 出 DirectMethod 类 型 函数 的 个 数 


int count = (int) pHeader->directMethodsSize; 


newClass->directMethodCount = count; 

// 为 DirectMethod 类 型 函数 分 配 数组 空间 

newClass->directMethods = (Method*) dvmLinearAlloc(classLoader, 

count * sizeof (Method)); 

/* 接 下 来 逐个 读 取 每 一 个 函数 ， 值 得 关注 的 是 ， 这 里 的 读 取 并 不 是 真正 的 读 取 ， 只 是 文件 
位 置 的 解析 ， 该 函数 的 Dalvik bytecode 二 进 制 文件 是 被 MAP 到 DVM 进程 里 ， 而 映 
射 动作 也 早已 完成 , 参见 相关 章节 。 这 种 设计 充分 利用 了 Linux 内 核 虚拟 内 存 体系 最 核 
心 最 有 效 的 机 制 ( 其 实 不 只 是 Linux， 应 该 说 是 整个 Unix 家 族 ， 包 括 Windows)。 这 
样 就 可 以 在 多 个 DVM 进程 共享 一 份 内 存 拷贝 , 而 且 在 物理 内 存 紧张 且 该 段 代码 不 被 经 常 
调用 时 , 又 可 以 释放 掉 那 块 唯一 的 物理 内 存 。 而 在 被 访问 时 又 被 Cache 进 Linux 的 Page 
Cache， 被 系统 所 有 需要 的 进程 访问 。 这 是 Dalvik 虚拟 机 设计 的 巧妙 之 处 ， 如 同 它 的 
进 线程 管理 ， 与 Linux 内 核 真正 融 为 一 体 */ 

for (i = 0; i < count; i++) { 

dexReadClassDataMethod (gpEncodedData, &method, &lastIndex); 
loadMethodFromDex (newClass, &method, &newClass-> 
directMethods[i]); 


} 
/*VirtualMethod 函数 的 加 载 ， 所 谓 VirtualMethod 指 的 是 Java 的 普通 函数 ,而 这 类 函 
数 的 调用 ， 要 通过 Vtable 进行 ， 一 个 class 的 vtable 的 建立 要 在 1ink 阶段 进行 */ 
if (pHeader->virtualMethodsSize != 0) { 
// 为 VirtualMethod 类 型 函数 的 个 数 


int count = (int) pHeader->virtualMethodsSize; 


// 为 VirtualMethod 类 型 函数 分 配 数 组 空间 
newClass->virtualMethods = (Method*) dvmLinearAlloc(classLoader, 
count * sizeof (Method)); 
/* 依 次 取出 VirtualMethod 类 型 函数 的 struct DexMethodId 结构 ， 并 初始 化 其 基本 
信息 〈 如 调用 规则 等 )， 代 码 映射 机 制 与 DirectMethod 类 型 函数 相同 ， 参 见 上 文 */ 

£0or (A = ED 了 HH { 
dexReadClassDataMethod (gpEncodedData, &method, g&lastIndex); 
loadMethodFromDex (newClass, &method, &newClass->Virtual 

Methods [i]); 


} 
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return newClass; 


19.3 对象 实 体 生 成 


Dalvik 中 对 象 的 生成 步骤 是 , 首先 加 载 待 生成 对 象 所 对 应 的 class 到 内 存 。Dalvik 首先 
检测 该 class 是 否 被 加 载 到 内 存 ， 否 者 需要 将 该 class 做 加 载 动作 ， 参 见 类 加 载 部 分 。 接 着 
在 Java 进程 heap 里 根据 该 类 描述 中 指出 的 类 对 象 所 占用 内 存 大 小 为 该 对 象 分 配 内 存 ， 从 

对 象 生成 的 典型 方式 是 通过 Dalvik 的 new 指令 ， 解 释 器 遇 到 对 象 生 成 指令 new 时 的 
handler 如 下 (以 C 解释 器 为 例 ): 


HANDLE OPCODE (OP NEW INSTANCE /*vAA, class@BBBB*/) 


{ 


} 


// 取 出 Dalvik 指令 里 指定 的 待 生成 对 象 的 类 索引 
ref = FETCH(1) 


/* 每 个 Dalvik 在 DEX 文件 控制 结构 里 记录 了 已 经 加 载 到 内 存 中 的 class， 这 里 首先 检 
查 该 class 是 否 已 经 被 加 载 了 */ 

clazz = dvmDexGetResolvedClass (methodClassDex, ref); 

if (clazz == NULL) { 

// 该 class 没有 被 加 载 ， 这 里 需要 先 加 载 该 class 
clazz = dvmResolveClass (curMethod->clazz, ref, false); 
if (clazz == NULL) 

GOTO_exceptionThrown (); 

} 

/* 隐 含 在 这 里 机 制 是 ， 基 础 类 库 、 常 用 类 库 被 大 多 数 Java 进程 使 用 ， 都 事先 加 载 了 ， 在 
新 的 dalvik java 进程 生成 时 fork 了 这 些 类 库 以 及 类 库 控 制 结 构 的 虚拟 内 存 空 间 ， 
以 后 新 的 dalvik java 进程 只 是 以 读 操作 访问 这 里 类 库 以 及 类 库 控制 结构 ， 物 理 内 存 
不 用 另外 分 配 ， 共 享 已 经 加 载 的 类 即 可 */ 


// 在 dalvik java 进程 的 heap 堆 里 分 配 该 对 象 
newObj] = dvmAllocObject (clazz, ALLOC DONT TRACK); 


FINISH (2); 


OP_END 
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// 对 象 生成 第 二 步 ， 为 对 象 实体 分 配 虚 拟 内 存 
Object* dvmAllocObject (ClassObject* clazz, int flags) 
{ 
Object* newObj; 
/* 基于 bionic 库 的 malloc 算法 在 java heap 上 分 配对 象 。clazz->objectsize 指出 
了 该 class 对 象 所 占 内 存 大 小 */ 


newOb]j 


(Object*) dvmMalloc (clazz->objectSize, flags); 
if (newObj != NULL) { 


/* 将 该 对 象 的 ClassObject* clazz; 指 针 指向 该 class 对 应 的 struct 
ClassObject 结构 */ 


DVM OBJECT INIT (newObj, clazz); 


} 


return newObj; 


第 20 章 Android 应 用 框架 


将 完全 符合 Linux 进程 模型 的 Android 应 用 程序 抽象 成 Android APP 开发 者 角度 看 到 
的 Android Java 编程 模型 ， 这 就 是 应 用 框架 所 起 到 的 作用 ， 本 章 探讨 Android API、 应 用 框 
架 、Linux 进程 模型 之 间 的 关系 。 

Android 的 应 用 框架 的 特点 如 下 : 

(1) 进程 中 有 大 量 本 地 对 象 和 与 之 对 应 的 代理 对 象 〈 位 于 另 一 个 进程 中 )。 在 C++ 层 
面 的 status_t IPCThreadState::executeCommand(int32_t cmd) 执 行 case BR_TRANSACTION: 
时 ， 本 地 对 象 的 status_t BBinder::transact 继而 调用 onTransact 函数 。 这 是 线程 池 中 的 线程 ， 
可 以 跑 到 Java 层 。DVM 中 (无 论 普通 进程 还 是 系统 进程 ) 的 Java 远程 对 象 对 本 地 对 象 的 
调用 都 是 这 种 方式 实现 的 。 

(2) 以 MainLooper 为 主体 的 主线 程 跑 class ActivityThread 的 代码 ， 不 停 地 接受 来 自 系 
统 组 件 消息 并 处 理 之 ， 这 演进 自 zygote fork 出 来 线程 。 

(3) Android UI 体系 实现 的 主体 是 在 应 用 进程 本 身 ，Android UI 系统 组 件 class 
WindowManagerService 仅 提供 事件 分 发 、 窗 口 管理 机 制 等 基本 控制 。 应 用 进程 获得 一 块 称 
之 为 surface 的 bitmap。 应 用 所 有 UI 的 泻 染 操作 都 是 由 运行 应 用 本 身 之 内 UI 类 库 完 成 。 
3D 的 实现 也 是 UI 类 库 的 一 部 分 ， 只 是 其 实现 可 由 硬件 完成 。 

(4) 应 用 框架 的 内 存 、 进 程 管理 、 文 件 操作 、 网 络 操作 、 访 问 控制 等 都 符合 Linux 传 
统 模型 ， 只 是 Java 层 的 编程 方式 不 同 而 已 。 

(5) 系统 组 件 作为 单独 的 DVM 进程 运行 。 从 内 核 角 度 看 ， 这 些 系统 进程 与 普通 线程 
无 异 。 只 是 某 些 访问 频繁 的 线程 如 surface flinger 的 优先 级 不 同 。 


20.1 ”线程 池 线 程 


线程 池 线程 是 Android 对 象 与 代理 机 制 的 运行 实体 ， 这 些 线程 由 系统 生成 ， 并 由 系统 
控制 运行 ， 将 Binder 驱动 连接 到 Java 层 是 理解 对 象 与 代理 的 调用 机 制 关 键 。 


20.1.1 C++ 层 


在 用 户 层 的 最 底部 ， 线 程 池 线程 作为 deamon， 检 测 内 核 Binder 驱动 并 实现 Binder 协 
议 ， 若 有 远程 对 象 调用 到 来 ， 线 程 池 线 程 执行 该 函数 : 
//Binder 协议 在 用 户 层 的 最 底层 实现 ， 仅 分 析 BR_TRANSACTION 情况 


status 七 ITPCThreadState: :executeCommand (int32 七 cmd) 
{ 
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case BR TRANSACTION: 


{ 


tree flags)s 


binder transaction data tr; 


//mIn 自 内 核 而 来 ， 将 内 容 考 入 tr 


result = mIn.read(gtr, sizeof (tr)); 


// 根 据 tr 初始 化 Parcel buffer， 这 里 面 携带 着 参数 信息 
Parcel buffer; 
buffer.ipcSetDataReference ( 


reinterpret cast<const uint8 t*>(tr.data.ptr.buffer), 


tr.data size, 
reinterpret cast<const size t*>(tr.data.ptr.offsets), 


tr.offsets size/sizeof (size t), freeBuffer, this); 


const pid t origPid = mCallingPid; 
const uid t origUid = mCallingUid; 
// 记 录 调 用 者 PID UID 

mCallingPid = tr.sender pid; 
mCallingUid = tr.sender euid; 


//replay 存放 返回 给 对 方 的 结果 
Parcel reply; 


/*tr.cookie 指出 了 本 地 对 象 的 指针 ， 这 是 内 核 识别 设置 的 ， 参 考 Binder 驱动 */ 
if (tr.target.ptr) { 


sp<BBinder> bl((BBinder*)tr.cookie); 
/* 本 地 对 象 的 调用 ,导致 onTransact 的 调用 , 无 论 C++ 还 是 Java 的 本 地 对 象 
都 会 重 载 onTransact， 以 实现 具体 功能 */ 


const status t error = b->transact (tr.code，buffer，&reply， 


} else { 


if ((tr.flags & TF ONE WAY) == 0) { 


// 给 对 方 返 回 结果 
sendReply (reply, 0); 


} else { 
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break; 


以 private class ApplicationThread extends ApplicationThreadNative 为 例 , 该 class 继承 自 
class Binder 并 重 载 了 public boolean onTransact(…) 了 函数。 在 远 端 进程 的 class 
ActivityManagerService 通过 class ApplicationThreadProxy 发 起 bindApplication 调用 后 。 应 
用 进程 的 线程 池 线 程 被 唤醒 ， 进 而 导致 class ApplicationThreadNative 的 onTransact 函数 被 
调用 ， 接 着 将 bindApplication 挂 入 class ActivityThread 的 消息 队列 即 返 回 。 

可 见 onTransact 函数 不 是 事件 处 理 的 主体 ， 其 主要 用 来 做 消息 通知 ， 有 具体 的 事件 处 理 
还 是 要 在 主线 程 里 完成 。 


20.1.2 Java 层 


Java 层 本 地 Binder 在 C++ 层 对 应 于 class JavaBBinder : public BBinder，onTransact 是 
class JavaBBinder 的 核心 函数 。 


// 自 status _t IPCThreadState::executeCommand (int32 七 cmd) 而 来 
virtual status t onTransact( 
uint32 t code，const Parcelg data, Parcel*reply, uint32 t flags = 0) 
{ 


// 调 用 Java 层 class Binder 的 private boolean execTransact (…) 函数 
jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets. 
mExecTransact, 
code, (int32 t)&data, (int32 t)reply, flags); 


} 


Java 层 本 地 Binder 的 private boolean execTransact(…) 函 数 ， 至 此 ， 线 程 池 的 线程 跑 到 
了 Java 层 , 并 成 为 Java 层 本 地 功能 对 象 命令 分 发 的 实体 线程 , 这 里 是 Android 应 用 框架 接 
双 Binder 机 制 关键 所 在 。 除 了 zygote 的 fork 机 制 、activitythread 的 mainlooper 机 制 ， 该 机 
制 与 Binder 一 起 成 为 Android 架构 实现 中 的 又 一 重要 机 制 。 


private boolean execTransact (int code, int dataObj, int replyObj, 
int flags) { 
Parcel data = Parcel.obtain (dataObj); 
Parcel reply = Parcel .obtain (replyObj); 


try { 
/* 对 onTransact 函数 的 调用 ，Java 层 本 地 功能 对 象 对 此 函数 重 载 ， 已 完成 自己 的 
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命令 分 发 */ 


res 


onTransact (code, data, reply, flags); 
a ed | 


20.2 ”系统 侧 Activity 与 Service 的 生成 控制 


Activity 或 Service 的 生成 有 两 方面 的 工作 , 在 系统 侧 控制 Activity 或 Service 在 新 的 进 
程 生成 还 是 在 原 有 进程 中 加 载 新 的 Activity 或 Service 。 前 者 意味 着 一 个 新 的 class 
ActivityThread 运行 单元 的 创建 ， 后 者 则 仅仅 意味 着 新 的 类 被 加 载 和 运行 。 


// 系 统 侧 生成 Activity 
private final void startSpecificActivityLocked (RctivityRecord Tv 
boolean andResume, boolean checkConfig) { 
// 从 记录 里 查找 对 应 应 用 记录 
ProcessRecord app = mService .getProcessRecordLocked 
(r.processName, 
r.info.applicationInfo.uid); 


// 如 果 系统 中 存在 对 应 应 用 且 有 执行 线程 
if (app != null && app.thread != null) { 
try { 
app.addPackage (r.info.packageName); 
/* 远 程 交互 其 对 应 的 activitythread， 调 用 其 scheduleLaunchActivity 
“Ff 
realStartActivityLocked(r, app, andResume, checkConfig); 
return; 


} 
/* 没 有 对 应 的 应 用 ， 这 里 将 生成 新 的 进程 ， 并 在 其 中 生成 Activitythread， 从 而 导致 
bindapplicatin 协议 的 执行 */ 
mService.startProcessLocked(r.processName, r.info.applicationInfo, 
true, 0, 


"activity", r.intent.getComponent (), false, false); 


// 青 看 service 的 生成 控制 
private final String bringUpServiceLocked (ServiceRecord LT， 


int intentFlags, boolean whileRestarting) { 


程 。 
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/* 检 查 该 服务 是 否 需要 隔离 运行 ， 意 味 着 该 service 可 以 与 其 他 activity、service 
在 同一 进程 里 运行 */ 


final boolean isolated = (r.serviceInfo.flags&ServiceInfo. FLAG 
ISOLATED PROCESS) != 0; 
// 如 果 不 需 要 则 隔离 运行 


if (!isolated) { 
// 在 系统 里 寻找 包含 该 service 的 已 运行 进程 
app = mAm.getProcessRecordLocked (procName, r.appInfo.uid); 


// 找 到 了 对 应 进程 
if (app != null && app.thread != null) { 
try { 
app.addPackage (上 .appInfo.packageName) 7 
/* 导 致远 程 activitythread 的 scheduleCreateService 被 调用 */ 
realStartServiceLocked(r, app); 


return null; 


} 


// 该 服务 需要 单独 在 一 个 进程 里 运行 ， 或 者 没有 对 应 的 线程 
if (app == null) { 
// 生 成 新 进程 及 activitythread， 并 绑 定 该 service 
if ((app=mAm.startProcessLocked(procName, r.appInfo, true, 
intentFlags, 


"service", r.name, false, isolated)) == null) { 


J 


生成 新 进程 的 方式 即 通过 socket 与 zygote 进程 间 交 互 , 再 通过 其 fork 机 制 生 成 新 的 进 
这 也 是 为 什么 systemserver 进程 里 塞 满 了 ActivityManagerService 、 


了 PackageManagerService、WindowManagerService 等 一 大 堆 服 务 ， 而 zygote 里 却 空空 如 也 。 


间 通 
自然 


因为 服务 组 件 之 间 交 互 是 相当 频繁 的 ， 把 服务 都 塞 在 systemserver 进程 里 避免 了 进程 
信 ， 为 了 其 高 性 能 将 服务 分 配 到 不 同 的 线程 即 可 。 而 zygote 是 用 来 fork 应 用 进程 的 ， 
里 面 不 能 塞 服务 ， 不 然 每 个 进程 fork 时 都 把 服务 带 进来 ， 岂 不 乱 了 套 。 
另外 ， 本 节 描 述 的 是 activity 和 service 生成 时 系统 侧 的 控制 机 制 ， 接 下 来 如 何 加 载 
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activity 和 service 还 是 由 新 进程 里 的 class activitythread 来 完成 的 。 
20.3 class ActivityThread 
class ActivityThread 类 的 main 是 DVM 主线 程 执行 的 主体 。class ActivityThread 的 实现 


决定 了 Android 进程 的 基本 线程 模型 ， 如 图 20-1 所 示 。 
( 线程 局 部 ) 


public void handleMessage(Message msg) { 
switch (msg what) { 
caseLAUNCH _ ACTIVITY- 


Callback mCallback 


licationThread mAppThread 
SE handleMessage 


case PAUSE _ ACTIVITY- 


case STOP_ ACTIVITY SHOW- 


schedulexxx 函 数 调用 void 
queueOrSendMessage(..) 生 成 各 种 class 
Message， 挂 在 class handler 的 mQueue 队 列 


LAUNCH _ ACTIVITY 


PAUSE ACTIVITY 


class Binder 
scheduleWindowVisibility 
scheduleResumeActivity 
scheduleBindService 
onTransact(): 调用 各 种 schedulexxx 


图 20-1 基本 线程 模型 


20.3.1 MainLooper 
Looper 机 制 不 是 主线 程 独 有 的 , 但 是 mainlooper 确 是 系统 中 唯一 的 , 它 与 主线 程 绑 定 ， 
是 主线 程 任务 分 发 的 中 心 。 


public class Looper { 


/* 该 looper 所 在 线程 的 线程 局 部 存储 ， 在 该 线程 中 通过 sThreadLocal 可 以 访问 到 该 
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looper*/ 
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper> (); 
// 一 个 进程 只 能 有 一 个 mainlooper、static 
private static Looper sMainLooper; // guarded by Looper.class 
//looper 的 消息 队列 


final MessageQueue mQueue; 


} 
Looper 使 用 的 第 一 步 是 与 线程 对 应 起 来 ， 代 码 如 下 : 
private static void prepare (boolean quitAllowed) { 
// 检 查 线程 局 部 存储 是 否 已 经 有 了 looper 
if (sThreadLocal.get() != null) { 
throw new RuntimeException("Only one Looper may be created 


per thread"); 
} 
// 新 建 一 个 looper， 并 存放 在 当前 线程 的 局 部 存储 中 
sThreadLocal .set (new Looper (quitAllowed)); 
» 


Mainlooper 的 构建 ， 代 码 如 下 : 
//looper 的 主体 


public static void prepareMainLooper() { 
//false 表示 主线 程 不 能 退出 


prepare (false); 


// 记 录 下 static 的 sMainLooper 
sMainLooper = myLooper(); 


} 


//looper 主体 函数 
public static void loop() { 


for (;;) { 
// 不 停 地 从 自己 的 消息 队列 中 取出 message 
Message msg = queue.next(); // might block 


/* 分 发 该 消息 。 该 消息 的 target 已 经 指出 了 其 分 发 的 handler*/ 
msg.target.dispatchMessage (msg); 


’ 

由 此 可 以 分 析出 主线 程 的 工作 模式 ， 线 程 池 线 程 携带 来 自 系 统 进程 的 命令 调用 class 
ApplicationThread 的 public boolean onTransact(…), 并 将 命令 以 消息 队列 的 形式 挂 载 到 主线 
程 的 消息 队列 ， 指 定 其 handler 为 class ActivityThread 的 私有 类 private class H extends 
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Handler， 然 后 线程 池 线 程 返回 。 

接着 主线 程 looper 取出 消息 队列 ， 并 执行 其 分 发 函数 。 即 为 private class H extends 
Handler 的 public void dispatchMessage(Message msg) 函 数 。 

进一步 分 析 private class H extends Handler， 它 就 像 是 一 个 DVM 系统 管理 的 门户 ， 诸 
如 LAUNCH ACTIVITY、SHOW_ WINDOW、BIND SERVICE、BIND _ APPLICATION 等 
来 自 系统 组 件 的 命令 都 由 这 里 分 发 。 


20.3.2 activity 与 service 的 加 载 


系统 侧 决 定 在 当前 进程 中 加 载 一 个 新 的 activity 时 ，class Activitythread 的 private void 
handleLaunchActivity(…) 将 导致 具体 执行 函数 private Activity performLaunchActivity(…) 被 
调用 ， 代 码 如 下 : 
/*activity 生成 通过 用 户 侧 与 系统 之 间 一 套 协议 来 完成 ， 网 上 已 有 很 丰富 的 描述 资料 ， 这 里 不 介 
绍 ， 本 书 侧重 介绍 Android 进程 模型 与 activity、service 之 间 的 关系 ， 这 里 只 分 析 其 加 载 */ 
private Activity performLaunchActivity (ActivityClientRecord r, Intent 
customIntent) { 


try { 
// 找 到 当前 应 用 所 在 package 对 应 的 类 加 载 器 
java.lang.ClassLoader cl = r.packageInfo.getClassLoader (); 
/* 这 里 其 实 就 是 调用 类 加 载 器 加 载 该 activity*/ 
activity = mInstrumentation.newActivity( 
cl, component.getClassName () r.intent); 


return activity; 


# 


系统 侧 加 载 服务 调用 导致 class Activitythread 的 private void handleCreateService(…)， 
人 们 也 仅 关 心 其 service 的 类 加 载 ， 代 码 如 下 : 


private void handleCreateService (CreateServiceData data) { 


try { 
// 找 到 该 service 所 在 package 对 应 的 类 加 载 器 
java.lang.ClassLoader cl = packageInfo.getClassLoader () 
// 加 载 


service = (Service) cl.loadClass (data.info.name) .newInstance (); 


} 


尽管 activity 和 service 创建 涉及 与 系统 侧 之 间 复 杂 绑 定 协议 和 activitythread 的 大 量 管 
理 结构 ， 但 是 从 其 类 加 载 机 制 可 以 清楚 地 看 出 activitythread 的 容器 功能 ， 无 论 是 什么 类 型 
的 activity 和 service， 都 不 过 是 activitythread 里 的 一 个 组 件 ， 其 加 载 机 制 决定 了 activity、 
service 与 activitythread 进程 的 动态 关系 。 


第 21 章 Android UI 体系 


Android UI 体系 由 系统 侧 和 应 用 侧 组 成 ， 系 统 侧 由 上 下 两 部 分 组 成 ， 上 层 部 分 即 class 
WindowManagerService ， 主 要 负责 消息 的 分 发 、 窗 口 栈 的 调整 ， 下 层 部 分 即 class 
SurfaceFlinger 负责 辣 加 计算 每 个 应 用 对 应 的 surface， 并 送 给 底层 的 Framebuffer 驱动 。 

应 用 侧 由 View 树 组 成 ， 接 受 服务 侧 上 层 class WindowManagerService 的 消息 ， 并 进行 
泻 染 操 作 。 其 泻 染 结果 直接 体现 在 应 用 侧 的 surface 中 。3D 硬件 加 速 以 Java 接口 的 形式 暴 
露 给 View 体系 ， 并 工作 在 应 用 侧 。 

本 章 整 理 自 较 早 版 本 笔记 ， 代 码 版 本 为 Android 1.X， 尽 管 与 Android 4.x 相 比 有 代码 
滞后 的 问题 ， 不 过 架构 方面 基本 相同 。 其 实 这 也 是 Android 的 特点 之 一 ， 由 于 设计 合理 ， 
Android 架构 一 直 没 有 大 的 变化 。 这 也 是 OS 技术 层面 成 功 的 关键 。 其 实 Android 问世 之 初 
很 多 基本 功能 并 没有 完全 实现 , 很 多 函数 甚至 是 空 的 。 但 是 由 于 其 合理 且 弹 性 的 架构 设计 ， 
版 本 演进 时 不 需要 架构 级 的 改动 ， 这 样 没有 来 得 及 实现 的 功能 逐步 如上， 系统 瓶 颈 的 地 方 
C 或 汇编 蔡 换 掉 ……,， 每 一 个 版 本 的 工作 都 没 浪费 , 成 为 以 后 版 本 更 新 的 基础 ，Android 

才能 稳步 成 长 到 现在 。 反 过 来 ， 再 看 一 些 技术 上 失败 的 OS 项 目 ， 最 重要 的 原因 是 架构 不 
清晰 或 者 没有 弹性 ， 往 往 动 辑 数 百人 的 投入 ， 尽 管 完成 了 不 少 局 部 功能 ， 但 是 却 形成 不 了 
合力 ， 架 构 一 改 再 改 ， 新 的 功能 搭 不 上 去 ， 很 多 版 本 被 废弃 掉 ， 完 成 不 了 积累 就 无 法 成 长 ， 
最 终 导 致 技术 上 失败 。 


21.1 窗口 体系 的 生成 


首先 class ActivityManagerService 在 启动 Activity 时 如 果 发 现 SHOW_APP 
_STARTING ICON， 则 导致 class WindowManagerService 的 public void setAppStarting 
Window(…) 被 调用 ， 接 着 导致 mPolicyaddStartingWindow(…) 被 调用 ， 导 致 class 
PhoneWindowManager 的 View addStartingWindow(…) 被 调用 ， 如 图 21-1 所 示 。 

应 用 程序 的 View 框架 则 是 在 class PhoneWindow 的 ViewGroup generateLayout 
(DecorView decor) 函 数 完成 的 : 

View in = mLayoutInflater.inflate(layoutResource, null); 

其 中 layoutResource 的 ID 指向 APPS/Common/res/layout/scree_title.xml 中 的 资源 文件 。 

而 应 用 程序 自身 定义 的 View 树 则 由 void setContentView(…) 生 成 (该 函数 由 OnCreate() 
调用 )， 其 中 内 容 是 应 用 指定 的 View 或 自身 的 layout.xml。 

分 析 Android 类 库 可 以 发 现 ， 整 个 UI 体系 就 是 一 个 集成 树 ， 如 class GridView、class 
AbsListView、class AdapterView、class ViewGroup、class View， 呈 现 依次 继承 关系 。 
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人 re ) 
Tbiner mToken 
Windowmanager mwindowmanager 
Window mwindow 
Class Phone Window 
(人 Class Localwindowmanager D 了 DecorView mDecor 1 
生成 于 “instaliDecor0”， 
调用 链 Oncreate0- 
| >setcontviewO- 
人 Ceswniowemeriepl ) 将 sc 的 时 的 ew 和 到 以 
| mDecor 为 root 的 树 中 
Viewl] mview 
Viewroot[] mroots |— | 
Class ViewRoot 
Class view 
Wmwindow 
Surface msurface 


图 21-1 调用 过 程 示 意图 


class View 是 View 的 祖先 ， 它 抽象 出 了 一 个 View 应 该 具有 的 onlayout、OnDraw、 
dispatchDraw、dispatchTouchEvnent、OnTouchEvnent 等 虚 函 数 。 这 样 不 同类 型 的 功能 类 通 

而 一 个 View 中 其 他 View 都 作为 其 孩子 存在 ， 所 以 当 某 个 事件 发 生 时 ， 通 过 对 孩子 的 
对 应 函数 调用 就 能 完成 泻 染 和 事件 响应 操作 。 这 种 面向 对 象 的 思想 是 UI 体系 发 展 的 方向 ， 
不 仅 解决 了 传统 窗口 体系 窗口 管理 器 的 瓶颈 问题 ， 如 布局 指令 的 由 传统 窗口 管理 器 做 的 工 
作 也 可 以 由 View 体系 来 完成 。 而 且 目 前 严重 依赖 3D 硬件 加 速 的 UI 体系 的 情况 也 从 这 个 
体系 受益 菲 浅 。 事 实 上 这 个 UI 架构 似乎 不 是 Android 上 独 有 的 ， 不 仅 IOS 的 II 泻 染 架构 
与 此 也 非常 类 似 ， 连 传统 义 也 似乎 要 被 以 Surface 为 中 心 的 wayland 取代 。 


21.2 ViewRoot 与 Surface 


ViewRoot 与 View 类 没有 任何 集成 关系 ，ViewRoot 是 应 用 UI 体系 与 系统 侧 
WindowManagerService 交互 的 接口 ， 通 过 ViewRoot、WindowManagerService 将 输入 事件 、 
窗口 事件 送 到 Android 应 用 ， 然 后 再 通过 Android View 体系 对 事件 的 响应 机 制 达到 接受 屏 
幕 点 击 坐 标 、 重 新 布局 、 重 画 VIEW 等 动作 。 

ViewRoot 的 构建 时 机 是 在 Activity 完成 View 创建 之 后 ，handleResumeActivity0 函 数 
被 触发 ， 代 码 如 下 : 


final void handleResumeRActivity(…) { 


wm.addView (decor, 1); 


. 
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从 而 导致 class WindowManagerImpl 的 public void addView(…) 被 调用 ， 接 着 触发 调用 
链 ， 如 图 21-2 所 示 。 


class WindowManagerlmpl: : addView 


| New ViewRoot >| Toot.SetView 
mWindowSession=IwindowManager.stub.asIn ”| SsWindowSession add0 
terface0.openSession 
一 | requestlayout 


L scheduleTraversals 


图 21-2 调用 链 


Surface 是 应 用 进程 泻 染 的 最 终 目的 地 ， 本 质 上 是 一 块 位 图 ， 且 跨 进 程 共享 。 其 共享 方 
式 是 通过 Binder 传递 文件 并 在 文件 映射 的 方式 中 进行 的 。Surface 的 生成 过 程 如 下 : 

(1) ViewRoot 第 一 次 执行 PerformTraversals 或 者 resize 时 ， 导 致 sWindowSession. 
relayout() 被 调用 。 

(2) WindowManagerService 创建 Surface。 

(3) ViewRoot 将 WindowManagerService 创建 的 Surface 记录 在 自己 的 mSurface 中 。 

(4) 在 ViewRoot 发 起 Draw 之 前 调用 Surface.lockcanvas， 得 到 canvas。 

(5) Surface.lockcanvas 实际 上 就 是 根据 底层 支持 的 surface 格式 创建 一 个 位 图 。 

(6) ViewRoot 把 这 个 canvas 传 给 View 体系 去 泻 染 。 


21.3 ”编辑 框 实例 分 析 


编辑 框 几乎 涉及 UI 体制 的 所 有 方面 。 本 节 以 编辑 框 为 例 来 整体 分 析 Android UI 体系 
的 工作 机 制 。 


21.3.1 ViewRoot 获得 系统 侧 代 理 对 象 


ViewRoot 是 Android View 体系 的 中 枢 ， 它 不 仅 要 与 到 系统 侧 WindowManageSevice、 
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InputMethodManagerService 等 系统 组 件 交 互 而 且 要 及 时 触发 View Tree 的 相关 动作 ， 涉 及 
Android View 体系 的 方方面面 。 要 和 系统 交互 就 需要 获得 系统 侧 组 件 的 代理 。 本 节 以 class 
JInputMethodManagerService 为 例 分 析 其 在 ViewRoot 里 的 代理 生成 。 

另外 ， 除 了 分 析 这 种 service 代理 对 象 的 生成 ， 本 节 还 将 分 析 非 service 对 象 的 生成 
实例 。 

没有 本 地 对 象 就 没有 代理 对 象 , 首先 分 析 系 统 侧 本 地 对 象 的 生成 , 系统 中 SystemServer 
创建 系统 级 输入 服务 class InputMethodManagerService， 并 将 其 注册 到 serviceManager 中 ， 
代码 如 下 : 


ServerThread. run() { 
ty 帮 


imm = new InputMethodManagerService(context, statusBar); 
ServiceManager.addService (Context.INPUT METHOD _ SERVICE， 

imm) 

/* 创 建 InputMethodqManagerService， 并 将 其 放 入 ServiceManager。 系 统 或 其 他 组 件 通过 
向 ServiceManager 查询 Context .INPUT METHOD SERVICE 来 获得 class InputMethod 
ManagerService 的 proxy*/ 

} catch (Throwable e) { 


} 


在 应 用 侧 ，class viewroot 中 生成 其 代理 ， 代 码 如 下 : 


public static IWindowSession getWindowSession (Looper mainLooper) { 


/*InputMethodManagerService 代理 生成 ， 这 是 通过 servicemanager 获得 代理 对 象 
的 机 制 。WindowManagerService 等 服务 的 代理 也 是 通过 这 种 方式 进行 的 。 而 对 于 一 些 
非 服 务 对 象 的 代理 的 获取 ， 如 WindowSession 代理 对 象 的 生成 ， 是 通过 对 Window 
ManagerService 远程 调用 来 完成 。 在 内 核 解 包 分 析 的 时 候 将 在 ServiceServer 进程 底 
下 生成 WindowSession 本 地 节点 ， 然 后 将 Binder 数据 包 挂 到 应 用 进程 的 时 候 将 
WindowSession 对 象 句柄 改 为 BINDER_TYPE_HRARNDLE 或 BINDER TYPE WEAK_ 
HANDLE 类 型 ， 且 在 应 用 进程 中 生成 引用 ， 并 指向 ServiceServer 进程 的 下 节点 。 具 体 分 
析 请 参见 Binder 章节 */ 

InputMethodManager imm = InputMethodManager.getInstance (mainLooper); 


} 
应 用 中 的 class InputMethodManager 实例 构建 及 典型 的 service 代理 对 象 的 生成 如 下 : 


static public InputMethodManager getInstance (Looper mainLooper) { 
synchronized (mInstanceSync) { 


// 先 到 servicemanager 里 找到 InputMethodManagerService 
IBinder b = ServiceManager.getService (Context.INPUT METHOD SERVICE); 
// 生 成 InputMethodManagerService 的 代理 对 象 
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IInputMethodManager service = IInputMethodManager .Stub. 


asInterface (b); 
mInstance = new InputMethodManager (service, mainLooper); 


} 


return mInstance; 


21.3.2 ”焦点 切换 事件 一 一 主要 Android Ul 机制 的 互动 


焦点 切换 事件 最 能 体现 Android UI 机制 的 工作 机 制 ， 它 几乎 涉及 所 有 主要 的 Android 
UI 机制 : WindowManagerService、InputMethodManagerService、ViewRoot、ViewTree， 以 
及 ViewTree 的 集成 与 重 载 关系 。 本 节 以 焦点 切换 事件 的 处 理 为 例 分 析 这 些 机 制 的 互动 

首先 WINDOW_FOCUS_CHANGED 消息 被 WindowManagerService 发 送 给 class 
ViewRoot。 在 class ViewRoot 里 ，WINDOW_FOCUS_CHANGED 消息 处 理 流程 如 下 : 


public void handleMessage (Message msg) { 
case WINDOW_ FOCUS CHANGED: { 


InputMethodManager imm = InputMethodManager.peekInstance () ; 
if (mView != null) { 
// 一 方面 向 ViewTree 分 发 焦点 改变 事件 
mView.dispatchWindowFocusChanged (hasWindowFocus) 


} 


/* 另 一 方面 如 果 获 得 焦点 ， 则 有 可 能 需要 提供 输入 操作 ,这 里 将 整 棵 View Tree 
交 给 InputMethodManager 来 处 理 */ 
if (hasWindowFocus) { 
if (imm != null && mLastWasImTarget) { 


/* 调 用 InputMethodManager 的 onWindowFocus 方法 来 处 理 FoCUS 事件 。 
这 里 参数 mView 为 ViewTree*/ 
imm.onWindowFocus (mView, mView.findFocus(), 
mWindowAttributes.softInputMode, 


!mHasHadWindowFocus, mWindowAttributes. 


flags); 


} break; 
当 WINDOW FOCUS_CHANGED 事件 被 转发 到 InputMethodManager 时 ,一 系列 函数 
被 触发 ， 代 码 如 下 : 


public void onWindowFocus(*…) { 
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// 一 方面 ， 向 ViewTree 分 发 焦点 检查 事件 


focusInLocked (focusedView != null ? focusedView : rootView) 
/* 男 一 方面 ， 对 于 InputMethodManager 自身 要 检查 焦点 ， 一 旦 确认 获得 焦点 需要 启 
动 输入 法 */ 


checkFocus (); 


. 
// 焦 点 检查 函数 


public void checkFocus() { 
/* 启 动 输入 法 ，InputMethodManager 自身 有 一 个 系统 侧 class InputMethod 
ManagerService 的 代理 对 象 ， 启 动 相关 输入 法 工作 将 通知 该 组 件 去 完成 */ 


startInputInner () 7 
} 


而 在 View 体系 中 , 当 一 个 需要 使 用 输入 法 获得 输入 的 View 在 收 到 焦点 改变 的 消息 时 ， 
都 要 调用 其 父 类 onFocusChanged 函数 ， 代 码 如 下 : 


Class View: :onFocusChanged (…) 
人 


imm.focusIn (this) 


// 这 里 告诉 输入 法 要 把 输入 送 到 哪个 View 
Class InputMethodManager:: focusInLocked (View view) 
站 


mNextServedView = view; 
} 
21.3.3 ”输入 事件 的 处 理 
在 处 理 完 焦点 切换 事件 之 后 ， 整 个 UI 机 制 就 可 以 进行 输入 操作 了 。 当 触摸 事件 或 鼠 


标 事 件 首先 被 windowmanagerservice 从 内 核 input 驱动 读 进来 之 后 ， 系 统 侧 的 
windowmanagerservice 找到 当前 最 顶层 窗口 对 应 的 ViewRoot， 将 事件 分 发 到 应 用 侧 。 


// 触 摸 事 件 被 送 进 viewroot 


private void deliverKeyEvent (KeyEvent event, boolean sendDone) { 


// 首 先 让 自己 的 ViewTree 来 处 理 该 触摸 事件 
boolean handled = mView != null 
? mView.dispatchKeyEventPrelIme (event) : true; 


if (handled) { 


// 如 果 该 事件 被 ViewTree 中 的 某 个 View 处 理 了 ， 则 直接 返回 


return; 
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} 


/* 和 否则 就 把 触摸 事件 交 给 InputMethodManager， 接 下 来 InputMethodManager 通 
过 代理 对 象 IInputMethodManager mService; 把 事件 提交 给 系统 侧 的 输入 法 管理 
器 ， 再 由 其 与 具体 的 输入 法 交互 */ 

if (mLastWasImTarget) { 


imm.dispatchKeyEvent (mView.getContext(), seq, event, 
mInputMethodCallback); 
return; 


} 
21.3.4 ”编辑 框 的 生成 


本 节 以 MMS 应 用 为 例 分 析 编 辑 框 生成 。 在 使 用 MMS 应 用 编辑 一 个 短 消息 时 会 启动 
-个 activity ， 这 个 activity 位 于 packages/apps/Mms/src/com/android/mms/ui/ 
ComposeMessageActivityjava， 描 述 其 UI 的 xml 文件 为 compose _ message_activityxml， 里 
面值 得 研究 的 是 短信 接收 入 编辑 框 。 
在 packages/apps/Mms/res/layout/compose_message_activity.xml 按 如 下 方式 定义 了 短信 
接收 入 编辑 框 : 
<ViewStub android:id="@+id/recipients editor stub" 
android:layout="@layout/recipients editor" 
android:layout width="fill parent" 


android:layout height="wrap_content" 


/> 
可 见 ， compose_message_activity.xml 并 没有 采用 普通 指定 类 名 , 而 是 采用 ViewStub 来 
描述 编辑 框 。 其 中 layout 指向 packages/apps/Mms/res/layout/recipients_editor.xml。 


<com.android.mms.ui.RecipientsEditor 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/recipients editor" 


is 
com.android.mms.ui.RecipientsEditor 指出 了 类 信息 。 接 下 来 看 这 个 编辑 框 是 如 何 生成 。 
// 首 先 看 初始 化 函数 


Private void initialize(Bundle savedInstanceState) { 


if (mConversation.getThreadId() <= 0) { 
// 仅 分 析 接 收入 为 空 的 情况 


initRecipientsEditor(); 
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// 编 辑 框 初始 化 
private void initRecipientsEditor() { 
ViewStub stub = (ViewStub)findViewById(R.id.recipients editor stub); 


if (stub != null) { 
// 将 编辑 框 recipients editor 给 inflate 出 来 
mRecipientsEditor = (RecipientsEditor) stub.inflate(); 
} else { 


} 


class ViewStub 本 质 上 就 是 个 class View， 一 个 View 使 用 class ViewStub 代替 自己 在 
UI 框架 中 占 个 位 置 ， 自 己 然后 再 动态 地 替换 掉 ViewStub。 


public View inflate() { 
// 找 到 ViewStub 的 父 View 
final ViewParent viewParent = getParent () 


if (viewParent != null && viewParent instanceof ViewGroup) { 
if (mLayoutResource != 0) { 
final ViewGroup parent = (ViewGroup) viewParent; 
/* 找 到 系统 中 LayoutInflater， 其 工作 就 是 inflate， 跟 普通 的 View 
inflate 一 样 ， 只 不 过 这 里 指定 父 View， 不 用 Inflater 再 为 自己 包 层 过 了 */ 

final LayoutInflater factory = LayoutInflater.from(mContext) 
/+ 执行 inflate， 就 是 根据 指定 的 资源 生成 相应 的 View*/ 

final View view = factory.inflate (mLayoutResource, parent, 

false); 


// 把 ViewStub 从 父 View 里 拿 掉 
final int index = parent.indexOfChild(this); 
Parent .removeViewInLayout (this) 


// 把 新 生成 View 加 到 父 View 中 
final ViewGroup .LayoutParams layoutParams = getLayout 
Params (); 
if (layoutParams != null) { 
Parent .addView (view, index, layoutParams); 
} else { 
Parent .addView (view, index); 
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ADB 尽管 只 是 Android 系统 的 一 个 调试 工具 ， 但 是 ABD 加 以 改造 ， 可 以 在 其 基础 上 
做 出 非常 实用 的 系统 功能 。 本 文 仅 分 析 ADB 手机 端的 行为 ， 且 仅 分 析 通 过 网 络 连接 情景 ， 
不 过 ADB 在 PC 端 和 手机 端 使 用 一 套 代 码 ，PC 侧 的 行为 可 参照 手机 侧 分 析 。 


22.1 ADB 基本 结构 


22.1.1 连接 


本 节 分 析 手 机 侧 ADB 与 远 端 建立 连接 的 过 程 。 


int adb main(int is daemon, int server port) 


/* 创 建 unix socket 句柄 对 transport registration send 、transport_ 
registration recv， 用 户 来 管理 连接 */ 


init transport_registration() :7 


// 检 查 init.rc 中 的 "service.adb.tcp.port" 是 否 置 位 
property get ("service.adb.tcp.port", value, ""); 


if (!value[0]) 
property get ("persist.adb.tcp.port", value, ""); 
if (sscanf (value, "%d", &port) == 1 && port > 0) { 
/* 若 "service.adb.tcp.port" 或 "persist.adb.tcp.port" 指 定 了 tcpport， 邦 
么 ADB 通过 网 络 连接 。void local init (int port) fork 出 连接 线程 ， 该 线程 是 
典型 的 1inux server 线程 : static void *server socket thread (void * arg)*/ 
local init(port); 
} else if (access("/dev/android adb", F OK) == 0) { 
// 否 则 如 果 存 在 /dev/android_adb 设备 ， 则 通过 USB 连接 
usb init(); 
} else { 
/ /否则 通过 默认 网 络 端口 连接 
local init (DEFAULT ADB LOCAL TRANSPORT PORT); 
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// 主 线程 循环 
fdevent loop(); 


return 0; 


// 连 接线 程 


static void *server socket thread(void * arg) 
{ 

int serverfd, fd; 

struct sockaddr addr; 

socklen t alen; 

int port = (int)arg; 


serverfd = -1; 
for(;;) { 
if(serverfd == -1) { 


//socket 调用 
serverfd = socket_inaddr_any_server (port， SOCK_STRERM) ; 


close_ on exec(serverfd); 


alen = sizeof (addr); 
// 在 该 端口 上 等 待 对 方 的 connect 
fd = adb socket accept (serverfd, &addr, &alen); 


// 成 功 连接 ， 取 得 句柄 
if(fd >= 0) { 


/* 创 建 代表 该 连接 的 struct atransport 结构 ， 该 结构 最 关键 的 成 员 变 量 为 :int sfd; 


一 一 记录 了 该 socket 句柄 
int (*read from remote) (...); 一 一 int remote read(...) 通 过 该 socket 从 远 端 读 
int (*write to remote) (...); int remote write(...) 通 过 该 socket 向 远 端 写 


然后 该 函数 通过 transport registration send 向 连接 管理 机 构 注 册 该 struct 
atransport 结构 */ 


register socket transport(fd; "host", port, 1):; 


} 


连接 管理 函数 static void transport_registration func(…) 运 行 在 主线 程 中 ， 对 于 每 一 个 
struct atransport 结构 都 创建 一 个 input_thread 和 一 个 output thread， 见 下 文 分 析 。 


第 22 章 ADB 381 


22.1.2 ”主线 程 


ADB 的 主线 程 是 void fdevent loop0, 该 线程 通过 select 机 制 不 断 检测 自己 关注 的 若干 
文件 句柄 上 是 否 有 事件 发 生 ， 若 有 事件 发 生 ， 将 为 对 应 文件 句柄 执行 处 理 函 数 。 代 码 如 下 : 


void fdevent loop() 


for(;;) { 
/* 检 测 文件 句柄 上 是 否 有 事件 发 生 ， 将 有 事件 发 生 的 句柄 收集 在 1ist_pending 链表 中 */ 


fdevent process(); 
// 依 次 取出 1ist_pending 链表 中 的 句柄 ， 执 行 其 处 理 函 数 
while((fde = fdevent plist dequeue())) { 
fdevent call fdfunc (fde) 


static void fdevent process() 

{ 
// 收 集 文件 句柄 位 图 集 
memcpy(&rfd，&read fds, sizeof (fd set)); 
memcpy(&wfd，&write fds, sizeof (fd set)); 
memcpy (&efd, &error fds, sizeof (fd set)); 


//Linux 系统 select 调用 
n = select(select n, &rfd, &wfd, &efd, NULL); 


// 有 事件 发 生 
for(i = 0; (i < select n) && (n > 0); i++) { 
events = 0; 
// 收 集 该 句柄 对 应 的 事件 
if(FD ISSET(i, &rfd)) { events |= FDE READ; n--; } 
if(FD ISSET(i, &wfd)) { events |= FDE WRITE; n--; } 


if(levents) { 
fde = fd tablelil; 


fde->state |= FDE PENDING; 
// 将 有 事件 发 生 的 句柄 记录 在 1ist pending 
fdevent plist enqueue (fde); 
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22.1.3 ”主线 程 监测 的 文件 句柄 


1. transport_registration_recv 


与 int transport registration send 组 成 unix socket 句柄 对 ， 和 触发 函数 为 static void 
transport registration func(int_ fd, unsigned ev, void *data)， 用 来 管理 连接 注册 。 


2. struct atransport 成 员 变量 transport_socket 


与 struct atransport 成 员 变 量 int fd; 组 成 unix_socket 句柄 对 ， 触 发 函数 为 static void 
transport_socket_events(int fd, unsigned events, void * t)， 用 来 管理 struct atransport 的 两 个 工 
作 线 程 : static void *input_ thread(void * D 和 static void *output thread(void * t)。 

3. 本 地 struct asocket 成 员 变量 int fd 

与 本 地 struct asocket 对 于 的 服务 线程 组 成 unix_socket 句柄 对 ， 当 服务 线程 侧 往 这 个 
unix_socket 写 操作 时 static void local _ socket_event func(...) 被 触发 ， 导 致远 端 对 等 struct 
asocket 结构 的 enqueue 等 函数 被 调用 。 

ADB 还 包括 struct atransport 的 两 个 工作 线程 : static void *input thread(void *_t) 和 | static 
void *output_thread(void)， 以 及 对 应 特定 命令 服务 线程 ， 这 些 线程 的 分 析 在 后 面 章节 介绍 。 


22.2 Transport 


Transport 的 主要 结构 是 一 个 struct atransport 和 两 个 struct asocket 对 等 对 。 


22.2.1 初始 化 


Transport 初始 化 的 主要 工作 包括 传输 机 构 的 注册 和 传输 线程 的 创建 ， 这 些 工 作 由 框架 
函数 transport_registration_func 实现 。 

//Transport 框架 函数 

static void transport registration func(int fd, unsigned ev, void *data) 


t 


/* 这 个 fd 即 为 static int transport registration recv, 与 static int 
transport registration send 组 成 一 对 unix socket， 这 里 读 取 static void 
*server socket thread (void * arg) 传送 过 来 的 transport 参数 (对 于 从 网 络 连接 
RDB 而 言 ) */ 


if(transport read action( fqd, gm)) { 
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fatal errno("cannot read transport registration socket"); 


//static void *server socket thread(void * arg) 创建 的 struct atransport 结构 


入 


= m.transport; 


if (t->connection state != CS NOPERM) { 


/* initial references are the two threads */ 

t=>ref Count = 27 

/* 对 于 一 个 新 注册 的 struct atransport，transport 管理 机 构 为 其 创建 两 个 线程 : 
static void *input thread(void * 七 ) 和 static void *output 
thread (void* 七 )， 并 且 创 建 一 个 unix_socket 句柄 对 ， 用 来 与 这 两 个 线程 通信 */ 

if(adb socketpair(s)) { 

fatal errno("cannot open transport socketpair"); 

} 

// transport _socket 是 transport 管理 机 构 侧 使 用 的 句柄 

t->transport socket = s[0]; 

// t->fd 是 另外 两 个 新 线程 使 用 的 句柄 

t->fd = s[1]; 


/* 若 另外 两 个 新 线程 往 unix_socket 写 入 内 容 ， 则 static void transport_ 
socket_events(…) 将 被 触发 */ 


fdevent install(&(t->transport fde), 
t->transport socket, 
transport socket events, 
七 ) 7 


// 将 select 检测 的 文件 集 相应 位 置 位 
fdevent set (g(t->transport fde), FDE READ); 


// 创 建 input_thread 线程 
if(adb thread create(&ginput thread ptr, input thread, t)){ 


fatal errno("cannot create input thread"); 


// 创 建 output _thread 线程 
if(adb thread create(g&goutput thread ptr, output thread, t+)){ 


fatal errno("cannot create output thread"); 


/* 将 该 atransport 串 起 来 */ 
adb mutex lock(gtransport lock); 
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t->next = &transport list; 
t->prev = transport list.prev; 
七 ->next->prev = t; 

七 


t->prev->next 


22.2.2 ”transport 传输 线程 


每 个 struct atransport 有 input 和 output 两 个 线程 ， 这 是 struct atransport 与 对 方 通信 的 
主要 工作 线程 。 


/* 从 远 端 到 transport 管理 函数 static void transport socket events(*…)*/ 


static void *output thread(void * 七 ) 
{ 
atransport *t = 七 7 
apacket *p; 
// 分 配 一 个 struct apacket 
p = get apacket (); 
p->msg.command = A _SYNC; 


// 向 static void transport socket events(…) 发 送 一 个 A_SYNC 命令 
if (write packet (t->fd, t->serial, &p)) { 


// 读 取 远 端 数 据 包 ， 青 传 给 transport 
for(;;) { 
P = get apacket (); 
/* 对 于 网 络 连 接 的 ADB， 该 函数 为 static int remote read(…)， 其 使 用 accept 
来 的 与 远 端 socket 链接 的 句柄 int sfq;， 从 远 端 读 取 数据 包 */ 


if(t->read from remote(p, t) == 0){ 
// 将 取 来 的 packet 写 到 static void transport socket events(**) 


if(write packet (t->fd, t->serial, &p)){ 


} else {… 


// 作 为 协议 的 一 部 分 再 写 一 个 A_SYNC 命令 
P = get apacket (); 
p->msg.command = A SYNC; 
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if(write packet (t->fd, t->serial, &p)) { 


// 将 数据 流 从 transport 管理 函数 static void transport socket events(…) 传输 到 远 


端 


static void *input _ thread(void * 七 ) 


{ 


atransport *t = t; 
apacket *p; 


int active = 0; 


for(;2;){ 
// 从 static void transport_socket_events (…) 读 取 数 据 包 


if(read packet (t->fd，t->serial，&p)) { 


if(p->msg.command == A_SYNC){ 
// 如 果 是 A_SYNC 则 调整 自己 状态 


} else { 
if(active) { 


/* 将 数据 写 向 远 端 ， 对 于 网 络 连接 的 ADB， 即 调用 函数 static int remote 
write (…) ， 该 函数 使 用 accept 来 的 远 端 socket 链接 的 句柄 int sfd;， 
向 远 端 写 数据 包 */ 
t->write to remotel(p, t); 
} else { 


return 0; 
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22.2.3 _ transport 的 管理 


当 远 端的 数据 到 来 ，select 的 transport fde 句柄 上 有 事件 发 生 ， 导 致 static void 
transport_ socket _ events(…) 被 触发 。 


static void transport socket events(int fd，unsigned events, void * 七 ) 


{ 


if(events & FDE READ){ 
apacket *p = 0; 
// 接 收 自己 input_thread，output_thread 传送 来 的 数据 包 
if(read packet (fd, t->serial, &p)){ 


} else { 
// 处 理 接收 到 的 数据 包 
handle packet(p, (atransport *) 七 ) 7 


. 


/* 数 据 包 的 处 理 ， 实 现 与 远 端的 交互 协议 ，ADB 交互 协议 参见 相关 文档 ， 这 里 仅 以 从 PC 通过 以 太 
网 连接 target 并 push 一 个 文件 到 板子 的 情景 来 分 析 */ 
void handle packet (apacket *p, atransport *t) 

{ 


asocket *s; 


Switch (p->msg.command) { 


case A _SYNC: 
/* 第 一 步 ,void handle_packet (…) 与 自己 的 input、output 线程 的 同步 ,通过 A_sYNC 


命令 来 实现 */ 


case A CNXN: /* CONNECT (version, maxdata, "system-id-string") */ 
/* 第 二 步 ， 收 到 A_CNXN 包 携带 connect 命令 而 来 ， 这 一 步 的 处 理 比较 简单 ， 主 要 向 对 
方 也 发 送 一 个 A_CNXN 包 即 可 */ 
if(t->connection state != CS OFFLINE) { 
t->connection state = CS_ OFFLINE; 
handle offline(t); 
} 


parse banner((char*) p->data, t); 
handle online(); 
if(!HOST) send connect (t); 


break; 


case A OPEN: /* OPEN (local-id, 0, "destination") */ 
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/* 第 三 步 ，push 命令 导致 一 个 A_OPEN 包 发 送 到 target*/ 


if(t->connection state != CS OFFLINE) { 
//push 命令 的 数据 包 里 指定 服务 名 为 sync: 
char *name = (char*) p->data; 
// 整 理 服务 名 


name[p->msg.data length > 0 ? p->msg.data _ length - 1 : 0] = 0; 
//asocket *create local _ service _ socket (…) 分 析 见 下 文 


5 = create local _ service socket (name) 
if(s == 0) { 
send close(0, p->msg.arg0, t); 
} else { 
/* 为 本 地 struct asocket 创建 一 个 对 等 结构 ， 代 表 远 端 ， 远 端 送 来 的 数据 包 指 
定 自己 的 ID, p->msg.arg0*/ 
53->peer = create remote socket (p->msg.arg0, t); 
5S->peer->peer = s; 
//ACK 远 端 一 个 A_OKAY 
send ready(s->id, s->peer->id, t); 
s->ready (s); 


} 


break; 


case A OKAY: /* READY (local-id, remote-id, "") */ 
// 第 四 步 ， 远 端 发 来 A_OKAY 
if(t->connection state != CS OFFLINE) { 
// 检 查 双方 的 对 等 struct apacket 是 否 建立 
if((s = find local socket (p->msg.arg1))) { 
if(s->peer == 0) { 
S->peer = create remote socket (p->msg.arg0, t); 
5S->peer->peer = s; 
} 


s->ready (s); 


. 


break; 


case A WRTE: 
// 第 五 步 ， 反 复 重复 的 步 又， 数据 传输 主要 由 A_WRTE 数据 包 携带 
if(t->connection state != CS_ OFFLINE) { 
// 寻 找 struct asocket 对 的 本 地 部 分 
if((s = find local socket (P->msg-argl))) { 


unsigned rid = p->msg.arg0; 
p->len = p->msg.data length; 
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// 执 行 其 int (*enqueue) (- . -) ;函数 ， 分 析 详 见 下 文 
if(s->enqueue(s, p) == 0) { 


send ready(s->id, rid, t); 
} 


return; 


asocket *create local service socket (const char *name) 
{ 

asocket *S7 

int fq; 


/* 通 过 int service to fd(const char *name) 创 建 sync: 的 服务 线程 ， 并 通过 一 个 
unix_socket 与 之 通信 ， 返 回 句柄 fd9， 即 为 该 unix_socket 的 句柄 */ 

fd = service to _fd(name) 7 

if(fd < 0) return 0; 


/* 创 建 一 个 struct asocket 结构 ， 并 将 其 加 入 local_socket_1l1ist 队列 , 该 struct 
asocket 结构 关键 成 员 函 数 int fq 即 为 与 上 述 sync :的 服务 线程 通信 的 unix_socket 的 
句柄 , 其 成 员 函 数 int (*enqueue) (…) ;为 static int local socket enqueue(*…)*/ 
3 = create _ local SockettEd) 
// 返 回 该 struct asocket 结构 指针 
FOtUrn 3 


} 
// 建 立 本 地 asocket 


asocket *create local socket (int fd) 
{ 
asocket *s = calloc(1，sizeof (asocket)); 
// 控 制服 务 线程 的 unix_socket 
s->fd = fd; 
// 数 据 包 来 到 时 调用 
S->enqueue = local socket enqueue; 
Ss->ready = local socket ready; 
s->close = local socket close; 
// 加 入 本 地 local socket 1ist 链表 
install local socket (s); 
/* 当 服务 线程 要 向 远 端 写 入 数据 时 ， static void local socket event func(…) 得 到 
调用 ， 该 函数 将 调用 本 地 asocket 的 远 端 对 等 asocket 的 int (*enqueue) (…) ;函数 ， 
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使 得 服务 线程 传 来 的 数据 送 到 远 端 */ 
fdevent install(&s->fde, fd, local socket event func, s); 


return S7 


/* 在 每 次 A WRTE 到 来 时 ,对 应 本 地 的 struct asocket 结构 的 int (*enqueue) (asocket *s, 
apacket *pkt) ;被 触发 */ 
static int local socket enqueue(asocket *s, apacket *p) 


{ 


// 若 该 包 携带 数据 

while(p->len > 0) { 

// 向 服务 线程 写 入 数据 ，s->fd 对 应 服务 线程 段 的 unix_socket 句柄 对 
int r = adb write(s->fd, p->ptr, p->len); 


22.3 Local 服务 


22.3.1 Local 服务 的 种 类 


Local 指 的 是 手机 或 嵌入 式 系统 上 的 特定 功能 。 
//Local service 通过 字符 串 name 来 索引 


int service to fdl(const char *name) 


int ret = -1; 


#if ADB HOST 


#else /* !ADB HOST */ 
} else if(!strncmp("dev:", name, 4)) { 
ret = unix_open (name + 4, O RDWR); 
} else if(!strncmp (name, "framebuffer:", 12)) { 
//framebuffer 服务 ， 抓 屏 


ret = create service thread (framebuffer service, 1 


390 拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 


} else if(recovery mode && !strncmp (name, "recover:", 8)) { 
//recover 服务 ， 升 级 


ret = create service _ thread (recoveT service， (void*) atoi (name + 


8)) 7 
} else if (!strncmp (name，"jdwp:"，5)) { 
//jdwp 链接 PC 调试 器 


ret = create jdwp connection fdl(atoi (name+5)); 


} else if (!strncmp(name, "log:", 4)) { 


// 抓 1og 
ret=create service thread(log service, get log file path (name + 
4)); 
} else if(!HOST && !strncmp (name, "shell:", 6)) { 
// 连 shell 


if(name[6]) { 
ret = create subproc thread (name + 6); 
} else { 
ret = create subproc thread(0); 
} 
} else if(!strncmp(name, "sync:", 5)) { 
// 最 常用 的 文件 传输 服务 ， 后 续 章节 详细 分 析 
ret = create service thread(file sync service, NULL); 
} else if(!strncmp (name, "remount:", 8)) { 
// 重 新 mount/system 目录 
ret = create service thread(remount service, NULL); 
} else if(!strncmp (name, "reboot:", 7)) { 
// 重 启 ， 要 等 vdc 完成 相关 工作 之 后 才能 执行 重启 
void* arg = strdup(name + 7); 
if(arg == 0) return -1; 
ret = create service thread(reboot service, arg); 
} else if(!strncmp(name, "root:", 5)) { 
/* 通 过 检查 ro .debuggable 来 决定 是 否 置 位 service.adb.root， 以 使 得 adb root。 手 
机 系统 上 并 不 是 每 次 都 能 成 功 ， 要 看 出 厂 设 置 */ 
ret = create service thread(restart root service, NULL); 
} else if(!strncmp (name, "backup:", 7)) { 
// 备 份 ， 通 过 /system/bin/bu 来 完成 
char* arg = strdup (name+7); 
if (arg == NULL) return -1; 
ret = backup service (BACKUP, arg); 
} else if(!strncmp (name, "restore:", 8)) { 
// 恢 复 ， 也 是 通过 /system/bin/bu 来 完成 
ret = backup service (RESTORE, NULL); 
} else if(!strncmp (name, "tcpip:", 6)) { 
// 通 过 设置 service.adb.tcp.port 触发 相关 动作 
int port; 
if (sscanf(name + 6, "%d", &port) == 0) { 
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port = 0; 
} 


ret = create service thread(restart tcp service, (void *)port); 
} else if(!strncmp (name, "usb:", 4)) { 
// 通 过 设置 service.adb.tcp.port 触发 相关 动作 

ret = create service thread(restart usb service, NULL); 
#endif 


return ret; 


} 


若 希 望 通过 ADB 实现 其 他 特殊 功能 , 也 需要 在 int service_to_fd(const char *name) 增 加 


22.3.2 Local 服务 的 形态 


ADB Local service 的 形式 是 以 独立 线程 形式 存在 的 ， 然 后 通过 unix_socket 与 之 通信 。 


// 创 建 一 个 ADB service 
static int create service thread(void (*func) (int, void *), void *cookie) 
{ 

stinfo *sti; 

adb thread 七 t; 

//unix_socket 的 一 对 文件 句柄 

int st213 

// 创 建 unix_socket， 句柄 放 在 int s[2] 里 

if(adb socketpair(s)) { 


} 

//stinfo *sti 用 来 存放 参数 

sti = malloc (sizeof (stinfo)); 

if(sti == 0) fatal ("cannot allocate stinfo"); 
sti->func = func; 

Sti->cookie = cookie; 

st4i=>fd = sl1]; 


// 创 建 独立 的 服务 线程 


if(adb thread create( &t, service bootstrap func, sti)){ 


return s[0]; 
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22.3.3 ”SYNC 服务 


以 SYNC 服务 为 例 分 析 ， 一 个 Local 服务 的 实现 。 当 Push 一 个 文件 到 target，SYNC 
服务 将 会 被 启动 。 
void file sync service (int fd, void *cookie) 


{ 


for(;;) { 
// 从 UNIX_SOCKET 里 读 取 文件 名 
if(readx (fd, é&msg.req, sizeof (msg.req))) { 


if(readx (fd, name, namelen)) { 


} 
//name 中 即 为 target 的 文件 名 


name [namelen] = 0; 


// Push 一 个 文件 的 写 入 操作 ， 对 应 的 ID 为 ID_SEND 
Switch (msg.req.id) { 
case ID STAT: 


case ID SEND: 
/* 在 处 理 完 链接 操作 之 后 ， 文 件 接收 的 主题 通过 static int handle_send_ 
file (…) 来 实现 ， 这 里 将 UNIX_SOCKET 句柄 传送 过 去 */ 
if(do_send(fd，name，buffer)) goto fail; 
break; 
case ID RECV: 


} 
} 


//UNIX_SOCKET 句柄 s 是 连接 远 端 的 纽带 
static int handle send file(int s, char *path, mode t mode, char *buffer) 


// 文 件 打开 操作 


fd = adb open mode(path, O WRONLY | O CREAT | O EXCL, mode); 
if(fd < 0 && errno == ENOENT) { 


mkdirs (path); 
fd = adb open mode(path, O WRONLY | O CREAT | O EXCL, mode); 
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// 文 件 接受 
for(;;) { 


// 读 取 包 头 
if(readx(s, &msg.data, sizeof (msg.data))) 
goto fail; 
// 检 查 是 否 为 数据 包 
if (msg.data.id != ID DATA) { 
// 是 否 到 了 文件 结束 
if(msg.data.id == ID DONE) { 
timestamp = LItohl (msg.data.size); 


break; 


} 


/* 读 取 数 据 , 数据 流 经 路 径 为 :从 static void *output_thread (void* 七 ) 到 struct 
asocket 的 int (*enqueue) (-.-);7 函 数 (static int local socket_ 
enqueue (…) )， 再 到 这 里 */ 

if(readx(s, buffer, len)) 
goto fail; 


// 写 入 target 本 地 文件 系统 
if (writex(fd, buffer, len)) { 


} 
// 文 件 写 入 成 ，ACK 远 端 
if(fd >= 0) { 
//ACK 包 将 携带 文件 戳 等 信息 到 远 端 
struct utimbuf u; 
adb close (fd); 
u.actime = timestamp; 
u.modtime = timestamp; 
utime (path, gu); 
// 状 态 置 为 OK 
msg.status.id = ID OKAY; 
msg.status.msglen = 0; 
// 写 到 远 端 
if(writex(s, &msg.status, sizeof (msg.status))) 
return -1; 
} 


return 0; 


和 


第 23 章 Android 浏览 器 的 Webkit 分 析 


随 着 HTML5 的 流行 ， 提 供 一 个 好 的 Webruntime 支持 成 为 OS 的 必 选 项 。Webkit 由 两 
部 分 组 成 : Webcore 和 js 引擎 。 前 者 的 工作 是 泻 染 html 脚本 ,后 者 是 js 执行 机 构 。 有 多 种 
s 引擎 实现 ， 本 书 着 重 于 V8 版 本 。 

本 章 Webcore 分 析 的 代码 版 本 为 Android 2.x 集成 的 Webkit，V8 部 分 由 于 在 PC 上 调 
试 较 容 易 ， 取 自 独 立 的 V8 代码 库 ， 版 本 为 2.2.14。 


23.1 Webcore 


Webcore 侧 的 工作 由 html 语法 解析 、Dom 树 的 构建 、rendering tree 的 构建 、layout、 
事件 接收 组 成 。 其 基本 工作 机 理 为 : Webcore 将 html 节点 做 语法 分 析 之 后 构建 以 html 语法 
节点 为 节点 的 DOM 树 ， 然 后 结合 CSS 生成 其 rendering tree， 该 rendering tree 上 的 每 个 节 
点 与 DOM 树 相 对 应 ， 是 其 泻 染 的 体现 形式 。 然 后 Webcore 从 rendering tree 根 节点 开始 逐 
个 画 出 每 个 rendering 节点 ， 其 中 每 个 rendering 节点 都 有 自己 的 泻 染 入 口 。 事 件 分 发 亦 是 
以 DOM 树 的 逻辑 结构 和 rendering tree 位 置信 息 为 依据 ， 将 事件 分 发 到 对 应 节点 上 。 


23.1.1 DOM 与 Rendering 树 生成 


在 经 历 html 语法 解析 之 后 ，html 脚本 中 的 语言 元 素 得 以 token 的 形式 表示 ， 
HTMLParser::parseToken(…) 函 数 将 逐一 处 理 这 些 token, 针对 不 同类 型 的 token 生成 其 DOM 
节点 ， 并 逐个 挂 入 DOM 树 上 ， 同 时 根据 DOM 节点 生成 Rendering 节点 。 这 样 DOM 树 和 
Rendering 树 同时 生长 ， 直 到 token 被 处 理 完 。 

// 语 法 元 素 作为 输入 ， 生 成 DOM 树 和 Rendering 树 

PassRefPtr<Node> HTMLParser: :parseToken (Token* t) 

{ 


/*t 是 一 个 元 素 ， 比 如 是 个 : <img src="home series.png">， 这 里 会 创建 class 
HTMLImageElement*/ 
RefPtr<Node> n = getNode (t); 


if (n->isHTMLElement()) { 
HTMLElement* e = static cast<HTMLElement*> (n.get ()); 
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// 在 class HTMLImageElement 类 型 的 节点 里 添加 src 属性 
e->setRAttributeMap (t->attrs.get ()); 


} 

/* 该 函数 把 生成 节点 插入 DOM 树 ， 在 insertnode 函数 中 会 针对 每 个 节点 调用 其 attach () 
函数 ， 从 而 导致 该 节点 对 应 的 rendering 对 象 的 生成 */ 

if (!insertNode (n.get()，t->selfClosingTag)) { 


} 
return n; 


} 
在 DOM 树 构 建 完毕 后 , Webcore 根据 DOM 树 生 成 rendering 树 , 接着 从 这 个 rendering 


tree 的 根 发 起 Layout。 


void FrameView::layout (bool allowSubtree) 

{ 
// 发 起 layout， 从 rendering tree 之 上 而 下 ，layout 
root->layout (); 

} 


接 下 来 以 如 下 脚本 为 例 ， 绘 制 其 DOM 树 和 Rendering 树 


<html> 

<head> 

<title>Titlep</title> 

</head> 

<body> 

shomepage <label>Thislabel </label>wang 
<label>senixlabel </label>sen 

</body> 

</html> 


生成 的 DOM 树 如 图 23-1 所 示 


与 之 对 应 的 rendering 生成 树 呈现 结构 如 图 23-2 所 示 。 
在 计算 节点 位 置 时 需要 对 依据 CSS 脚本 的 信息 ，CSS 的 解析 主要 是 通过 lex 和 yacc 


[ 具 完 成 ， 中 间 生 成 文件 位 于 android\out\target\product\generic\obj\SHARED _LIBRARIES\ 


libwebcore_intermediates\WebCore\CSSGrammar.cpp。 


// 其 中 Css 解析 的 入 口 函 数 如 下 ， 主 要 动作 分 为 两 步 

bool CSSStyleSheet: :parseString (Const String &string，bool strict) 
二 

// 动 态 生 成 CSSParser 对 象 
CSSParser pl(strict); 
// 解 析 获 取 的 Css 字符 
p-:parseSheet (this, string); 
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图 23-2 ”rendering 生成 树 


在 CSSParser::parseSheet 中 使 用 lex and yacc 工具 分 析 CSS 语法 。 
23.1.2 ”事件 的 产生 与 分 发 


首先 分 析 事 件 处 理 函 数 的 挂 载 , 在 构建 DOM 树 时 ， 如 果 该 节点 上 有 相应 的 处 理 函 数 ， 
则 在 该 节点 生成 以 后 ， 要 在 节点 上 挂 接 该 节点 的 事件 listener。 以 后 当 Webcore 引擎 分 发 事 
件 到 该 节点 时 ， 就 会 顺 着 注册 好 的 listener 找到 处 理 函 数 。 

事件 类 型 是 繁杂 的 ， 但 是 其 处 理 流 程 是 相同 的 ， 以 一 种 事件 处 理 为 例 可 以 分 析出 整个 
事件 处 理 机 制 ， 下 面 以 如 下 script 脚本 为 例 : 


<html> 
<head> 


<script language="LiveScript"> 
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function pushbutton() { 
alert ("hello"); 


} 
</script> 


</head> 
<body> 
<form> 
<input type="button" name="Buttonl" value="Push me" onclick= 


"pushbutton () "> 
</form> 
</body> 
</html> 
节点 处 理 机 制 的 挂 载 要 从 节点 生成 看 起 ， 再 次 分 析 节 点 处 理 函 数 ， 这 里 要 关注 对 节点 
的 属性 处 理 。 
PassRefPtr<Node> HTMLParser::parseToken (Token* 七 ) 


{ 
if (n->isHTMLElement()) { 
HTMLElement* e = static cast<HTMLElement*>(n.get()); 


// 从 这 里 进去 ， 挂 接 event 的 处 理 1istener 
e->setAttributeMap (t->attrs.get ()); 


} 

对 于 每 个 继承 自 class Element 的 节点 ,其 属性 被 集中 存放 在 类 型 为 class NamedAttrMap 
的 namedAttrMap 变量 中 ， 这 里 不 去 考虑 其 实现 细节 ， 将 其 当 作 一 个 容器 即 可 。 在 构建 完 
一 个 节点 之 后 ，Webcore 把 从 parser 分 析出 来 的 属性 列表 储存 到 这 个 容器 中 。 

// 属 性 收集 

void Element::setAttributeMap (PassRefPtr<NamedAttrMap> list) 


{ 
if (namedAttrMap) { 


for (unsigned i = 0; i < len; i++) 
// 属 性 更 新 事件 
attributeChanged (namedAttrMap->m attributes[i] .get ()); 


} 


对 于 本 例 ，parser 分 析出 class HTMLInputElement 类 型 的 节点 拥有 如 下 属性 : type、 
name、value、onclick。 在 将 这 些 属性 存 入 namedAttrMap 之 后 ， 还 要 针对 每 个 属性 触发 更 
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void StyledElement::attributeChanged (Attribute* attr, bool preserveDecls) 
{ 
if (needToParse) // 对 于 某 些 类 型 的 属性 需要 进一步 处 理 
parseMappedAttribute (mappedAttr); 


$i 


继承 至 class Element 有 多 种 节点 ， 每 种 节点 都 有 自己 感 兴趣 的 属性 更 新 。 对 于 class 
HTMLInputElement， 它 重 载 了 parseMappedAttribute 函数 ， 显 然 它 关心 width、height、 
onfocus、onselect 等 属性 ， 对 于 onclick，class HTMLInputElement 并 不 关心 ， 将 其 甩 给 它 
的 父 类 处 理 。 

void HTMLInputElement: :parseMappedAttribute (MappedAttribute *attr) 

{ és 
// 交 给 父 类 处 理 
HTMLFormControlElementWithState: :parseMappedAttribute (attr); 


. 


class HTMLInputElement 的 父 类 class HTMLFormControlElement 仍然 不 关心 这 个 
onclick 属性 ， 继 续 甩 给 其 父 类 。 


void HTMLFormControlElement::parseMappedAttribute (MappedAttribute *attr) 
! 


// 真 正 处 理 的 地 方 
HTMLElement: :parseMappedAttribute (attr); 


} 


这 里 ，class HTMLElement 处 理 了 onclick 属性 的 更 新 ， 值 得 注意 的 是 : class 
HTMLElement 处 理 了 generic 的 UI 事件 类 属性 的 更 新 ， 如 onmousedown、onmouseup、 
onkeydown 、onkeyup 等 。 


void HTMLElement::parseMappedAttribute (MappedAttribute *attr) 
{ 


// 设 置 listener 


setInlineEventListenerForTypeAndAttribute (eventNames () .clickEvent, 
允 丰 让 于》 以 


} 


所 有 的 DOM 树 上 的 节点 都 继承 于 class Node, 在 class Node 中 有 一 个 存放 该 节点 所 有 
listener 的 容器 一 一 class NodeRareData 类 型 的 容器 。 所 有 节点 的 容器 都 被 放 到 类 型 为 class 
NodeRareDataMap 的 更 大 容器 里 ， 每 个 Node 的 实例 用 自己 的 指针 去 那个 更 大 容器 里 去 找 
存放 自己 listener 的 class NodeRareData 类 型 的 容器 。 

setInlineEventListenerForTypeAndAttribute 的 主要 工作 是 构建 一 个 listener, 并 加 入 到 这 
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个 节点 的 listener 容器 中 。 


void EventTargetNode::setInlineEventListenerForTypeAndAttribute (const 
AtomicSstringg& eventType, Attribute* attr) 


{ 

/* 

构建 该 类 型 事件 的 listener 且 调 用 class ScriptController 的 
createInlineEventListener 函数 来 创建 类 型 为 class JSLazyEventListener 的 
listener 。 注意 class JSLazyEventListener 的 成 员 函数 void 
JSAbstractEventListener: :handleEvent， 在 事件 分 发 到 该 节点 后 ， 它 将 被 触发 

bd 

setInlineEventListenerForType (eventType, 
document () ->createEventListener (attr->localName () .string(), attr-> 
value(), this)); 
! 
// 展 开 分 析 1istener 的 挂 载 
void EventTargetNode: :setInlineEventListenerForTYype (const AtomicString& 
eventType, PassRefPtr<EventListener> listener) 
{ 

// 把 以 前 注册 到 容器 中 的 时 间 1istener 除去 

removeInlineEventListenerForType (eventType); 

if (listener) 

// 将 新 的 1istener 加 入 到 容器 中 

addEventListener (eventType, listener, false); 


. 


接着 分 析 事件 的 产生 与 分 发 ， 首 先 事 件 产生 来 自 Android 系统 侧 ， 自 驱动 到 
windowmanagerservice 再 到 Web 进程 的 viewroot， 然 后 通过 WebViewCore 将 事件 传 入 
Webcore。 


//webcore 承接 事件 的 函数 

WebViewCore: :finalKitFocus 

{ 

frame->eventHandler () ->handleMouseMoveEvent (mouseEvent); 


. 


bool EventHandler: :handleMouseMoveEvent (const PlatformMouseEVventE& 
mouseEvent， HitTestResult* hoveredNode) 
{ 
// 事 件 定位 
MouseEventWithHitTestResults mev = prepareMouseEvent (request, 
mouseEvent); 
// 分 发 
swallowEvent = dispatchMouseEvent (eventNames () .mousemoveEvent, mev. 
targetNode(), false, 0, mouseEvent, true); 
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事件 正式 进入 到 WebCore， 继 续 事件 分 发 ， 函 数 如 下 : 


bool EventTargetNode::dispatchGenericEvent (PassRefPtr<Event> prpEvent) 
handleLocalEvents (event .get (), false); 
} 


在 该 节点 的 listener 容器 中 需要 与 event 事件 匹配 的 listener， 找 到 之 后 即 触发 其 
handleEvent 函数 。 


void EventTargetNode: :handleLocalEvents (Event* event, bool useCapture) 


{ 


RegisteredEventListenerVector listenersCopy = eventListeners(); 
size t size = listenersCopy.size(); 


for (size t i = 0; i < size; ++i) { 


// 接 到 event 


r.listener()->handleEvent (event, false); 


} 
函数 eventListeners 的 作用 其 实 就 是 去 找 该 节点 的 listener 容器 。 


const RegisteredEventListenerVectorg EventTargetNode::eventListeners() 
const 


{ 
if (hasRareData()) { 
lL (RegisteredEventListenerVector* listeners = rareData () 


->listeners ()) 
return *listeners; 


} 


在 上 节 中 可 以 看 到 class JSLazyEventListener 类 型 的 listener 已 经 被 加 入 到 容器 中 ， 在 
确认 其 匹配 的 事件 类 型 后 ， 其 handleEvent 函数 被 触发 。 


23.2 V8 parser 源码 分 析 


笔者 曾 将 该 节 内 容 发 表 在 论坛 中 ， 本 节 是 整理 精简 之 后 的 版 本 。(V8 版 本 号 : 2.2.14) 
V8 对 js 的 脚本 处 理 流程 如 图 23-3 所 示 。 
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parser 生 成 抽象 语法 树 ， 这 里 将 每 一 句 js 
语句 〈statement) 生成 为 一 个 节点 


| 


本 地 代码 引擎 将 抽象 语法 树 生成 对 应 的 
二 进 制 代码 ， 依 次 取出 每 个 节点 ， 不 同 
类 型 的 节点 有 着 不 同 代码 生成 方法 


执行 ， 遇 到 新 的 函数 调用 再 次 启动 这 个 
过 程 ( 这 时 是 lazy_parser) 


图 23-3 V8 对 js 的 脚本 处 理 流程 


本 节 分 析 的 正 是 这 个 流程 第 一 步 。 
23.2.1 V8 parser 处 理 脚本 的 层次 


(1) 进入 FunctionLiteralt MakeAST(…)， 这 里 分 辨 出 要 处 理 的 是 json 还 是 普通 的 js 
脚本 ， 普 通 的 js 脚本 通过 调用 parserParseProgram(…) 处 理 。 

(2) 进入 FunctionLiteral* Parser::ParseProgram(…)， 这 是 个 wrapper， 主 要 工作 如 下 : 

Q@ 构建 该 脚本 运行 时 所 需要 的 scope， 以 及 编译 时 需要 的 Scanner。 

@ 对 该 脚本 语法 抽象 树 的 生成 工作 主要 由 void* Parser::ParseSourceElements(…) 完 成 ， 
生成 的 结果 放 在 准备 的 容器 ZoneListWrapper<Statement> body(16) 中 。 

@ 根据 生成 结果 生成 FunctionLiteral 类 型 的 返回 结果 。 

(3 ) 进入 void* Parser::ParseSourceElements(…), 这 里 的 逻辑 很 简单 ,就 是 用 Statement* 
Parser::ParseStatement(…) 将 每 行 js 语句 分 析出 来 ， 每 条 js 语句 被 解析 成 Statement。 


V8 中 Parser 定义 如 下 : 
class AstBuildingParser : public Parser { 


// 对 应 脚本 

Handle<Script> script ; 

// 脚 本 扫描 器 ， 将 脚本 输入 流 来 处 理 成 一 个 个 有 效 元 素 
Scanner scanner 

// 作 用 域 ， 对 应 于 变量 定义 作用 域 概念 ， 这 里 代表 最 高 层 作 用 域 


Scope* top scope ; 


//Expect 函数 实际 上 将 scanner 的 指针 往 后 移动 
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void Expect (Token::Value token, bool* ok) 7 


AstBuildingParserFactory factory ; 


// 语 法 分 析 

FunctionLiteral* Parser::ParseProgram(Handle<String> source, 
bool in global context) { 

// Scanner scanner 初始 化 


scanner .Initialize(source, JAVASCRIPT); 


FunctionLiteral* result = NULL; 
// 这 里 top_scope 为 NULL 


// 生 成 一 个 新 的 class Scope， 其 parent 为 NULL 
Scope* scope = factory()->NewScope (top_scope , type, inside with()) 7 
/* LexicalScope 的 构造 函数 里 将 class parser 的 top_scope 指针 指向 刚 生 成 scope*/ 
LexicalScope lexical scope(this, scope); 
TemporaryScope temp_ scope (this); 
ZoneListWrapper<Statement> body(16); 


bool ok = true; 


// 对 于 最 上 层 top scope， 其 结束 标志 是 Token: :EOS 
ParseSourceElements (gbody, Token::EOS, &ok); 


if (ok) { 
// 生 成 对 应 于 当前 脚本 的 FunctionLiteral 
result = NEW(EunctionLiteral (…) ) 7 


// 对 于 一 个 Js 函数 的 分 析 


FunctionLiteral* Parser::ParseFunctionLiteral (Handle<String> var name, 
int function token position, 


FunctionLiteralType type, 
bool* ok) { 
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int num _ parameters = 0; 
// 函数 体 分 析 
{ Scope::Type type = Scope::FUNCTION SCOPE; 
/* 进 入 一 个 函数 体 中 ， 这 是 新 一 层 作 用 域 ， 为 这 个 函数 体 新 生成 一 个 class Scope 的 实例 ， 其 父 
scope 为 top scope */ 


Scope* scope = factory()->NewScope (top scope , type, inside with()); 


/* 对 于 本 层次 class LexicalScope， 在 其 构造 函数 里 将 其 prev_scope 指针 记录 着 上 一 
层 的 top_scope_, 而 class parser 的 top_scope 被 指向 新 生成 的 scope, 而 在 class 
LexicalScope 析 构 函数 里 将 恢复 class parser 的 top_scope 为 构造 函数 里 记录 的 


prev_scope */ 


LexicalScope lexical scope(this, scope); 
TemporaryScope temp scope (this); 


top_scope ->SetScopeName (name); 


// 出 现 “(”， 表 明 函 数 声明 的 开始 
Expect (Token: :LPAREN, CHECK OK); 
int start pos = scanner .location() .beg pos; 
bool done = (peek() == Token: :RPAREN); 
// 如 果 紧 接着 出 现 “) ”， 表 明 这 个 函数 没有 参数 ， 否 则 分 析 其 参数 
while (!done) {// 分 析 该 函数 参数 
Handle<String> param name = ParseIdentifier (CHECK OK); 
if (!is pre parsing ) { 
// 把 参数 加 入 到 该 scope 中 
top_scope ->AddParameter (top_scope ->DeclareLocal (param name, 
Variable: :VAR)); 
num parameterst++; 
} 
done = (peek() == Token: :RPAREN); 
if (!done) Expect (Token::COMMA, CHECK OK); 
. 
// 终 于 出 现 “)”， 该 函数 参数 列表 分 析 完 毕 
Expect (Token: :RPAREN, CHECK OK); 


// 出 现 “{” 一 个 函数 体 的 开始 
Expect (Token: :LBRACE, CHECK OK); 
/*Class ZoneListWrapper 实际 上 是 容纳 其 模板 类 型 实例 的 一 个 列表 ， 这 里 其 容纳 的 是 
Statement 列表 */ 
ZoneListWrapper<Statement> body = factory()->NewList<Statement> (8); 
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if (!function name.is null() && function name->length() > 0) { 
// 生 成 一 个 变量 ， 其 名 字 为 该 函数 名 
Variable* fvar = top scope ->DeclareFunctionVar (function name); 
// 生 成 一 个 变量 代理 
VariableProxy* fproxy = 
top_ scope ->NewUnresolved (function name, inside with()); 
// 将 变量 及 变量 代理 绑 定 起 来 
fproxy->BindTo (fvar); 
/* 首 先生 成 一 个 Assignment 表达 式 的 实例 ， 其 target 为 fproxy， value 为 class 
ThisFunction 的 实例 ，class ThisFunction 本 身 就 是 一 个 表达 式 : class 
ThisFunction: public Expression*/ 


body.Add (new ExpressionStatement ( 
new Assignment (Token::INIT CONST, fproxy, 
NEW (ThisFunction()), 


RelocInfo::kNoPosition))); 


if (is lazily compiled && pre data() != NULL) { 


} else { 
// 这 里 对 脚本 逐 语 句 分 析 
ParseSourceElements (gbody, Token::RBRACE, CHECK OK); 


this property assignments = temp_ scope.this property assignments(); 


Expect (Token: :RBRACE, CHECK OK); 


int end pos = scanner .location() .end pos; 


//parser 的 结果 放 在 这 里 
FunctionLiteral* function literal = 
NEW (FuNctionLiteral (...); 
if (!is pre parsing ) { 
function literal->set function token position(function token_ 
position); 
} 
seen loop stmt = true; 


return function literal; 


406 拨 云 见 日 一 一 基于 Android 的 内 核 与 系统 架构 源码 分 析 


23.2.2 Scope 


在 parser 分 析 到 一 个 变量 定义 时 ， 以 一 个 函数 内 的 变量 声明 并 赋值 为 例 : 


var senix; 


var senix=123; 


首先 parser 在 分 析 到 第 一 条 语句 时 ， 语 句 处 理 函 数 : Block* Parser::Parse 
VariableDeclarations(bool accept_IN, Expression** var bool* ok) {…} 一 个 重要 举措 是 在 当前 
scope 里 declare 这 个 变量 。 而 scope 的 declare 函数 在 接 到 这 个 任务 之 后 ， 触 发 如 下 动作 : 

(1) 在 当前 变量 列表 中 查找 是 否 有 同名 变量 。 

(2) 如 果 没 有 同名 变量 ， 在 当前 scope 中 创建 一 个 新 的 变量 class Variable。 

(3) 为 该 变量 生成 变量 代理 VariableProxy， 并 将 其 加 入 当前 scope 的 
ZoneList<VariableProxy*> unresolved_ 队 列 和 ZoneList<Declaration*> decls_ 队列 。 

(4) 将 该 变量 代理 class VariableProxy 绑 定 到 class Variable。 

在 该 scope 将 生成 parser_scope_1 的 结构 ， 如 图 23-4 所 示 。 


=: 


class VariableMap: public 
HashMap T hash 
class Scope: public ZoneObject Entry* map_ 了 
class VariableProxy: public Class Variable 
VariableMap variables | Expression 
list Handle<String> mame_ 
变量 绑 定 
本 = LU 区 站 Handle<String> name 
ZoneList<VariableProxy*> pp Variable* var ; Mode mode_ 
unresolved 
VariableProxy* proxy_ Expression® rewrite_ 
对 于 var senix; 语 司 在 
ldir 和 ) 对 于 var senix; 语 句 在 
ee | 处 生成 
int nnm_heap_ slots : 


图 23-4 parser_scope_1 的 结构 


接着 parser 在 分 析 到 第 二 条 语句 时 ， 这 是 个 赋值 语句 ， 生 成 的 赋值 节点 包括 代表 senix 
的 class VariableProxy 类 型 变量 和 代表 123 的 class Literal 变量 ，scope 演变 成 图 
parser_scope_ 2 的 结构 如 图 23-5 所 示 。 

这 时 可 以 看 到 ， 第 二 句 赋值 语句 仅仅 指向 了 一 个 变量 代理 ， 而 没有 真正 指向 该 变量 。 
该 变量 代理 与 变量 的 绑 定 在 第 三 步 完 成 。 

在 完成 了 脚本 parser 以 后 ， 下 一 步 就 是 使 用 生成 二 进 制 代码 了 ， 在 生成 二 进 制 代码 之 
前 必须 进行 变量 的 解析 ， 这 里 完成 class VariableProxy 到 class Variable 的 绑 定 。 

parser 需要 在 当前 的 scope 里 declare 这 个 变量 。 对 于 一 段 js 脚本 ， 每 个 层次 都 对 应 一 
个 class Scope， 该 层次 上 的 变量 、 作 用 域 范围 与 此 scope 紧密 相关 。 如 脚本 文件 以 及 该 文 
件 里 的 函数 是 两 个 层次 的 scope。 
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class VariableMap public 
HashMap 有 Ta 
class Scope: public ZoneObject Enty* map_ | 
| class VariableProxy: public 
VarisbleMap variables_ 9 | class Variable 
| 四 
ZoneList<Declarationr> decls_ eh > 
| \ Sealecseing mame 
ZoneList<VariableProxy*> py Variable* var; 
resolved Mode mode 
VariableProxy* proxy_ 
对 于 var senix: 语 名 在 Expression® rewrite 
SS 对 于 warsenic 语 句 在 
a -Declare( ) 
int mum stack_slots ; ee We 
int mum_heap_slots ; 
| chass VariableProxy: public 
Expression 
Handle<String> name_ 
Variabler var : 
ET 
(0) 的 “case 
Takea:IDENTIFIER-" 处 生 
成 ， 代 表 "senix” 
class Assignment: public 
Expression public AstNode 
| class Literal: public Expression 
Token-Valoe op ; 
Handle<Object> handle_; 
Expression mrget virtual void Accep AstVicitor” 
六 
Expression® valoe ; 
Target 是 “=" 左 侧 表达 式 ， 对 于 语句 
value_ 是 “=” 右 侧 表达 式 senix=123,Parser:-ParsePrimary 
Expression( ) 的 case 
Token-:NUMBER-: 处 生成 代 
表 "123" 


图 23-5 ”parser_scope 2 的 结构 


脚本 文件 的 scope 生成 如 下 : 
FunctionLiteral* Parser::ParseProgram(Handle<String> source, 
bool in global context) { 


/* 根 据 参 数 bool in_global_context 判定 该 Scope 是 何 种 类 型 ， 对 于 脚本 文件 级 ， 
in_global_context 为 1， 该 Scope 的 类 型 为 GLOBAL SCOPE*/ 


Scope: :Type type = 
in global context 
? Scope::GLOBAL SCOPE 


: Scope::EVAL SCOPE; 


// 为 该 级 的 js 代码 创建 Scope， 对 于 js 文件 级 ，top_scope 为 NULL 
factory() ->NewScope (top_scope , type, inside with()); 


Scope* scope = 
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} 
具体 Scope 创建 根据 Parser 类 型 不 同 而 异 ， 对 于 class AstBuildingParser， 其 创建 函数 
如 下 : 


Scope* AstBuildingParserFactory: :NewScope (Scope* parent, Scope::Type type, 
bool inside with) { 
Scope* result = new Scope(parent, type); 
result->Initialize (inside with); 


return result; 


23.2.3 ”语法 分 析 的 入 口 Parser::ParseStatement(…) 


在 该 函数 里 进行 实质 的 语法 分 析 。 这 是 一 个 分 拣 器 : 分 析出 每 个 js 语句 的 类 型 ， 然 后 
针对 不 同 的 类 型 再 进一步 调用 相关 的 分 析 函 数 。 上 具体 流程 操作 过 程 是 ， 首 先 分 离 出 有 关键 
字 的 statement。 这 些 statement 由 关键 字 指明 ， 有 很 清楚 的 含义 ， 如 var forest;， 接 下 来 交 
给 专门 的 statement 分 析 器 再 进行 更 清楚 的 分 析 。 比 如 var 语句 交 给 Block* 
ParseVariableStatement(bool* ok);， 让 语句 交 给 IfStatement* ParselfStatement(ZoneStringList* 
labels, bool* ok);， 交 给 而 对 于 普通 语句 如 forest=1876+forest3;、 函 数 调 用 等 语句 Statement* 
ParseExpressionOrLabelledStatement(ZoneStringList* labels,bool* ok); 做 进一步 分 析 。 

源码 解析 如 下 ， 其 分 拣 工作 由 一 个 switch 进行 。 


Statement* Parser::ParseStatement (ZoneStringList* labels, bool* ok) { 
switch (peek()) { 


case Token::CONST: // fall through 
case Token::VAR: 
//VAR 变量 声明 语句 
stmt = ParseVariableStatement (ok); 
break; 


case Token::IF: 
//IF 语句 
stmt = ParseIfStatement (labels, ok); 


break; 


case Token::TRY: { 
//try 语句 


Block* result = NEW(Block (labels, 1, false)); 
Target target (this, result); 
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case Token: :FUNCTION: 
// 遇 到 一 个 函数 


return ParseFunctionDeclaration (ok); 


default: 
// 普 通 语句 走 到 这 里 
stmt = ParseExpressionOrLabelledStatement (labels, ok); 


23.2.4 ”普通 语句 的 分 析 


接 下 来 分 析 遇 到 具体 的 JS 语法 元 素 时 的 处 理 。 
1 变量 声明 


当 遇 到 一 个 var Token，parser 使 用 Block* Parser::ParseVariableDeclarations(bool 
accept_IN, Expression** Var, bool* ok) {…} 来 分 析 这 个 语句 。 


Block* Parser::ParseVariableDeclarations (bool accept _IN, 
Expression** var, 
bool* ok) { 


Variable::Mode mode = Variable::VAR; 
bool is const = false; 
if (peek() == Token::VAR) { 
// 将 parser 的 扫描 器 指针 向 前 推进 到 Var 后 面 的 位 置 
Consume (Token: :VAR); 
//CONST 语句 与 VAR 处 理 相同 
else if (peek() == Token::CONST) { 
// 将 parser 的 扫描 器 指针 向 前 推进 到 CONST 后 面 的 位 置 
Consume (Token: :CONST); 
mode = Variable::CONST; 
is_const = true; 
} else { 
UNREACHABLE(); // by current callers 


// 生 成 一 个 class Block: public BreakableStatement 节点 
Block* block = NEW(Block (NULL, 1, true)); 


VariableProxy* last var = NULL; // the last variable declared 


int nvars = 0; // the number of variables declared 
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do 1{ 
/* 对 于 多 个 变量 的 声明 语句 ， 将 parser 的 扫描 器 指针 向 前 推进 到 变量 声明 的 逗号 后 面 */ 
if (nvars > 0) Consume (Token::COMMR) Handle<String> name = 
ParseIdentifier (CHECK_OK) ; // 提 取出 当前 变量 的 标识 符 


// 在 当前 scope 里 声明 该 变量 ， 这 是 最 重要 的 一 步 
last var = Declare (name, mode, NULL, 
is const /* always bound for CONST! */, 


CHECK OR); 


nvarstt+; 


Expression* value = NULL; 


int position = -1; 


// 对 于 有 初始 值 的 声明 ， 按 赋值 表达 式 处 理 
if (peek() == Token::ASSIGN) { 
Expect (Token: :ASSIGN, CHECK OK); 
position = scanner() .location() .beg pos; 
value = ParseAssignmentExpression(accept IN, CHECK OK); 


} while (peek() == Token: :COMMA); 


return block; 


2. AssignmentExpression 表达 式 


对 一 个 AssignmentExpression 表达 式 的 分 析 以 forest=99 为 例 ， 代 码 如 下 : 


Expression* Parser::ParseAssignmentExpression(bool accept IN, bool* ok) { 
/* 对 于 “=” 左 边 ， 执 行 Parser: :ParseConditionalExpression， 该 函数 返回 “=” 左 侧 
的 表达 式 ， 对 于 forest=99; 分 析 “=” 左 边 的 表达 式 */ 


Expression* expression = ParseConditionalExpression (accept_IN， 
CHECK_OK); 
// 如 果 接 下 来 token 不 是 “=”， 直 接 返 回 该 表达 式 

if (!Token::IsAssignmentOp(peek())) { 


// Parsed conditional expression only (no assignment). 


return expression; 


Token::Value op = Next(); // Get assignment operator. 
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// 取 出 下 一 个 操作 符 ， 对 于 forest=99; ，op 为 “=?” 
int pos = scanner() .location() .beg pos; 
// 分 析 “=” 右 边 的 表达 式 


Expression* right = ParseAssignmentExpression(accept IN, CHECK OK); 


/#* 左 右 两 侧 的 语法 结构 都 已 分 析 完 毕 ， 根 据 生 成 的 左右 表达 式 和 操作 符 op 生成 语句 iforest=99 
的 statement*/ 


return NEW(Assignment (op, expression, right, pos)); 


3. LogicalOrExpression '? AssignmentExpression :' AssignmentExpression 表达 式 


/* 该 函数 分 析 诸 如 LogicalOrExpression '?' RssignmentExpression ':' 
RssignmentExpression 的 语句 */ 
Expression* Parser::ParseConditionalExpression (bool accept IN, bool* ok) { 


// 分 析 LogicalOrExpression 部 分 ， 即 “? ” 左 侧 
Expression* expression = ParseBinaryExpression(4, accept IN, CHECK OK); 


/ /如果 该 语句 只 有 LogicalOrExpression 部 分 ， 则 peek 不 到 “?” 返回 
if (peek() != Token::CONDITIONAL) return expression; 
//scanner 的 指针 移 过 “? ” 

Consume (Token: :CONDITIONAL); 


// 分 析 前 一 个 RssignmentExpression 部 分 即 “? ”和 “: ”之 间 的 表达 式 
Expression* left = ParseAssignmentExpression(true, CHECK OK); 
// 检 查 是 否 下 面 出 现 了 “:” 
Expect (Token: :COLON, CHECK OK); 
// 分 析 后 一 个 AssignmentExpression 部 分 即 “: ”后 面 的 表达 式 


Expression* right = ParseAssignmentExpression(accept_ IN, CHECK OK); 
return NEW(Conditional (expression, left, right)); 


} 


4. 用 ParseBinaryExpression(…) 分 析 “?” 左 侧 的 表达 式 


二 元 函数 分 离 器 Expression* Parser::ParseBinaryExpression(…):， 看 起 来 云 里 雾 里 ， 不 


得 其 解 。 其 实 这 是 因为 其 原 函 数 号 
析 将 其 主干 。 


有 很 多 代码 是 用 来 优化 statement 的 ， 先 将 优化 部 分 去 掉 分 


这 个 函数 使 用 了 一 个 重要 工具 : Expression* ParseUnaryExpression(…):， 该 函数 暂且 可 


以 理解 为 在 一 串 操 作 序 列 中 


取出 第 一 个 操作 数 ， 以 atbtc 为 例 ，Expression* 


ParseUnaryExpression(…); 返 回 对 应 a 的 表达 式 。 
再 者 操作 符 都 有 自己 的 优先 级 , int Precedence(Token::Value tok, bool accept_IN); 这 个 函 
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数 就 是 取出 对 应 操作 符 的 优先 级 〈 操 作 符 优 先 级 的 定义 参见 token.h)。 

该 函数 最 大 的 特点 是 递归 分 析 ， 其 每 次 递归 下 探 的 深度 ， 取 决 由 操作 符 的 优先 级 。 每 
次 Parser::ParseBinaryExpression(…) 使 用 Expression* ParseUnaryExpression(…), 取出 第 一 个 
操作 数 后 ， 它 会 检查 在 取出 的 操作 数 后 的 操作 符 的 优先 级 是 否 大 于 《高 于 ) 该 操作 数 之 前 
操作 符 的 优先 级 。 如 果 不 是 ， 就 复 然而 止 ， 递 归 探 底 。 这 种 情况 下 函数 Expression* 
Parser::ParseBinaryExpression(…) 实 际 上 就 等 效 于 Expression* ParseUnaryExpression(…)， 代 
码 如 下 : 


Expression* Parser::ParseBinaryExpression(int prec, bool accept IN, bool* 
ok) { 
ASSERT (prec >= 4); 
// 取 出 第 一 个 操作 数 
Expression* x = ParseUnaryExpression (CHECK OK); 
/* 如 果 接 下 来 操作 符 的 优先 级 (Precedence (peek () ，accept_IN) ) 低 于 第 一 个 操作 数 前 面 操 
作 符 的 优先 级 (int prec)， 就 向 上 返回 了 */ 


for (int precl = Precedence (peek(), accept IN); precl >= prec; precl--){ 
// 跑 到 这 里 说 明 遇 到 了 更 高 优先 级 的 操作 符 
// precl >= 4 
while (Precedence (peek () ，accept_IN) == precl) { 
// 取 出 这 个 操作 符 
Token::Value op = Next(); 
/* 去 取 下 一 个 操作 数 ， 参 数 precl + 1， 说 明 同一 等 级 的 操作 符 不 会 通过 递归 进行 。 而 是 用 这 个 
while 循环 逐个 分 解 */ 
Expression* y = ParseBinaryExpression(precl + 1，accept_IN，CHECK_OK) ， 
// 生 成 新 的 表达 式 
x = NEW(BinaryOperation(op, x, y)); 


} 
return x; 


} 
再 看 完整 的 代码 : 
// Precedence >= 4 


Expression* Parser::ParseBinaryExpression(int prec, bool accept_IN, bool* 


ok) { 


// 先 进行 一 元 表达 式 分 析 
Expression* x = ParseUnaryExpression (CHECK OK); 
for (int precl = Precedence (peek (), accept IN); Precl >= prec; precl--) 
{ 
// precl >= 4 
while (Precedence (peek() ， accept IN) == Erecl) { 
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Token: :Value op = Next(); 
// 逐 层次 分 析 二 元 表达 式 分 析 
Expression* y = ParseBinaryExpression (Precl +1, accept IN, CHECK _ OK) 
/* 如 果 x 和 y 都 是 数字 就 直接 算出 结果 ， 合 并 表达 式 。 不 然后 面 的 二 进 制 生成 器 要 对 每 个 表达 式 都 
生成 一 遍 代码 */ 
if (x && x->AsLiteral() && x->AsLiteral()->handle()->IsNumber() && 
Y && Y->RsLiteral () && y->AsLiteral()->handle()->IsNumber ()) 
double x val = xX->RsLiteral ()->handle () ->Number (); 
double y val = y->AsLiteral () ->handle () ->Number (); 


{ 


switch (op) { 
case Token::ADD: 


x = NewNumberLiteral(x val + y val); 
continue; 


case Token::SAR: { 
uint32 t shift = 


DoubleToInt32(y val) & Oxlf; 
int value = 


ArithmeticShiftRight (DoubleToInt32(x val), shift); 
x = NewNumberLiteral (value); 
continue; 
} 
default: 
break; 


// 如 果 y 是 数字 且 是 除法 操作 ， 就 直接 算出 结果 ， 合 并 表达 式 


// Convert constant divisions to multiplications for speed. 
if (op == Token::DIV && 


y && y->AsLiteral() && Y->RAsLiteral ()->handle ()->IsNumber ()) 
double y val = Y->RAsLiteral ()->handle () ->Number (); 
int64 七 Y_int = 


有 


static cast<int64 t>(y val); 


} 


return x; 


5. 分 析 一 元 表达 式 


该 函数 的 功能 是 : 要 么 分 离 出 一 元 表达 式 ， 要 么 分 离 出 普通 表达 式 ， 代 码 如 下 : 
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Expression* Parser::ParseUnaryExpression(bool* ok) { 


// 先 取出 操作 符 
Token: :Value op = peek(); 
// 检 查 操作 符 是 否 为 一 元 表达 式 操作 符 
if (Token::IsUnaryOp(op)) { 
// 取 下 一 个 元 素 
op = Next(); 


Expression* expression = ParseUnaryExpression (CHECK OK); 


if (expression != NULL && expression->AsLiteral() && 
expression->RAsLiteral()->handle ()->IsNumber()) { 


} else if (Token::IsCountop (op)) { 


} else { 
// 不 是 一 元 表达 式 
return ParsePostfixExpression (ok); 
} 
} 


基础 表达 式 分 析 以 表示 符 为 例如 下 : 


Expression* Parser::ParsePrimaryExpression(bool* ok) { 
switch (peek()) { 


case Token::IDENTIFIER: { 

/* 最 基本 的 表示 符 都 会 跑 到 这 里 ， 对 于 forest=99;， 等 号 左 侧 的 forest 分 析 最 终 会 走 到 
这 里 */ 

// 取 出 标识 符 将 其 放 入 name 变量 
Handle<String> name = ParseIdentifier (CHECK OK); 


if (is pre parsing ) { 
= 
} else { 
/* 创 建 一 个 class VariableProxy 类 型 的 对 象 , 并 将 其 放 入 在 当前 的 scope 里 的 unresolved_ 
列表 中 */ 


result 


VariableProxySentinel::identifier proxy(); 


top_scope ->NewUnresolved (name, inside with()); 
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break; 


case Token: :NUMBER: { 
/* 扫 描 器 碰 到 了 一 个 数字 ， 对 于 forest=99;， 分 析 等 号 右 侧 的 99， 最 终 会 走 到 这 里 */ 
Consume (Token: :NUMBER); 
// 在 V8 内 部 是 用 一 个 双 精 度数 来 表示 数字 
double value = 
StringToDouble (scanner .literal string(), ALLOW HEX | ALLOW_ 
OCTALS); 


result = NewNumberLiteral (value); 
break; 


return result; 


23.3 指令 生成 


在 V8 parser 生成 语法 树 之 后 , 接 下 来 是 生成 二 进 制 指令 。 其 基本 做 法 是 ,按照 语法 树 
的 基本 结构 ， 依 次 遍历 其 上 的 节点 ， 然 后 根据 每 个 节点 的 类 型 ， 找 到 其 二 进 制 指令 的 生成 
器 。 这 些 不 同 的 节点 类 型 有 着 其 对 应 的 AstVisitor。 

Class AstVisitor 位 于 src/asth， 对 应 于 AST NODE， 对 于 不 同 的 ASTNODE 有 不 同 的 
Visitor。 


class AstVisitor BASE EMBEDDED { 
void Visit(AstNode* node) { if (!CheckStackOverflow()) node-> Accept 


(this); } 


#define DEF VISIT (type) \ 
virtual void Visit##type (type* node) = 0; 
AST_NODE LIST (DEF VISIT) 

#undef DEF VISIT 

}; 


#define RST NODE LIST(V) \ 
V(Declaration) % 
STATEMENT NODE LIST (V) 后 


EXPRESSION NODE LIST(V) 
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可 见 AST 节点 列表 包含 了 statement 列表 和 表达 式 列表 。 


#define STATEMENT NODE LIST(V) \ 
V(Block) 本 

#define EXPRESSION NODE LIST(V) \ 
V(FunctionLiteral) 党 


另 一 方面 ， 对 于 每 种 架构 的 处 理 器 ， 都 会 有 自己 的 class CodeGenerator ， 在 


SIC/XXX/codegen-xxx.h: 


class CodeGenerator: public AstVisitort{ 


/* 该 函数 体现 了 二 进 制 指令 生成 基本 结构 ， 这 又 是 一 个 面向 对 象 的 方法 : 语法 树 体现 脚本 的 逻辑 结 
构 和 调用 关系 ， 其 上 语法 节点 对 应 着 不 同 的 Visitor， 其 二 进 制 指令 的 生成 是 由 这 些 Visitor 
具体 完成 的 */ 

void Visit(AstNode* node) { if (!CheckStackOverflow()) node-> Accept 

(this); } 


. 


class CodeGenerator 里 会 实现 Class AstVisitor 里 的 VisitXXXXX 函数 ， 而 所 有 表达 式 
继承 于 class RegExpTree， 所 有 statement 继承 于 class AstNode， 这 两 个 类 里 都 定义 了 虚 函 
数 virtual void Accept(AstVisitor* Vv); 这 些 表达 式 和 statement 的 accept(…) 函 数 的 具体 实现 
在 astcc 中 : 

#define DECL ACCEPT (type) 二 

void type::Accept (AstVisitor* v) { v->Visit##type (this); } 
AST_NODE LIST (DECL ACCEPT) 
#undef DECL ACCEPT 


可 见 ，AST_NODE LIST 节点 列表 包含 了 statement 列表 和 表达 式 列表 ， 每 种 
STATEMENT_NODE 和 EXPRESSION NODE 的 accept 函数 为 v->Visit##type(this);。 这 样 
语法 树 被 送 到 CodeGenerator 后 ， 针 对 不 同类 型 的 节点 执行 不 同 AstVisitor 的 Vist 操作 ， 即 
调用 其 VisitXXXX 函数 生成 二 进 制 指令 。 


